2018년 상반기 Memcache의 반사 증폭 계수가 거의 50,000에 달하는 덕분에 DDoS의 최대 트래픽은 전례 없는 새로운 높이인 1.7Tbps에 도달했으며, 이로 인해 Memcache ReDDoS는 현재 DDoS의 백본이 되었습니다. Memcache ReDDoS와 비교하면 2016년 Akamai가 노출한 CLDAP ReDDoS는 이전만큼 효율적이지는 않지만 56~70배의 증폭률은 여전히 DDoS 계열의 선두주자이므로 주목을 받을 만합니다.
LDAP(Lightweight Directory Access Protocol)는 RFC2251(LDAPv3)에 정의되어 있으므로 LDAP는 필요한 바인딩 작업과 빈번한 데이터 검색 쿼리에 더 많은 TCP를 사용합니다. 그래서 IETF는 1995년에 CLDAP(connectionless Lightweight Directory Access Protocol)를 발표했습니다. 공식 문서는 RFC1798입니다(2003년에 RFC3352는 CLDAP를 기록 상태로 설정했습니다). CLDAP에서는 searchRequest, searchResponse(searchResEntry 및 searchResDone), 포기요청의 세 가지 작업만 제공됩니다. 인증 기능이 제공되지 않으면 클라이언트는 UDP 데이터그램을 사용하여 LDAP 서버 포트 389에 대한 작업 요청을 시작할 수 있습니다. 클라이언트가 searchRequest를 시작한 후 서버는 searchResEntry 및 searchResDone이라는 두 개의 응답 메시지를 반환하므로 일반적으로 이 작업을 수행하면 더 큰 데이터 패킷을 반영하는 더 작은 데이터 패킷의 효과가 발생하고 이 결함은 반사 증폭 DDoS 공격을 수행하는 데 악용됩니다. .
Akamai SIRT에서 발표한 보고서에 따르면 현재 캡처된 CLDAP ReDDoS의 최고 피크 트래픽은 24Gbps이며 최대 반사 배수는 70배입니다. CLDAP는 널리 사용되지 않으므로 오픈 소스 LDAP 소프트웨어 openLDAP는 더 이상 UDP 프로토콜 요청을 지원하지 않습니다. 실제로 CLDAP ReDDoS 공격에 가장 많이 악용되는 서비스는 Windows 서버의 AD(Active Directory)입니다. 일반적으로 AD 서비스는 TCP 포트 389에서 클라이언트의 LDAP 작업 요청을 수신하고 UDP 포트 389에서 CLDAP 프로토콜을 사용하여 rootDSE 검색 작업을 기다립니다(rootDSE 항목은 AD 서비스가 구성될 때 생성되며, 무단 액세스를 허용합니다. 인증된 클라이언트는 서버에 구성 상태, 기능 및 확장된 속성("AD ping"이라고도 함)을 쿼리합니다. 일부 Windows 서버의 AD 서비스 수신 포트는 공용 네트워크에 노출된 후 증폭된 반사 DDoS 공격을 생성하기 위해 rootDSE 쿼리를 실행하는 데 악용됩니다. 보안 연구원들은 Exploit-DB에서 Perl 공격 스크립트를 공개했습니다. 취약점을 확인하기 위해 Nmap의 ldap-rootdse 스크립트를 사용하여
nmap -Pn -sSU 389,636 --script ldap-rootdse <target_ip>
을 스캔할 수도 있습니다. 결함이 있는 서버가 rootDSE 항목, 항목 속성 및 기타 구성 정보를 반환하는 것을 볼 수 있습니다.
Exploit-DB의 rootDSE CLDAP ReDDoS 익스플로잇 스크립트의 페이로드는 다음과 같습니다.
LDAP와 CLDAP는 데이터를 전송할 때 먼저 데이터를 LDAP 메시지로 캡슐화합니다. ASN.1에서 BER을 사용하여 인코딩된 다음 온라인 도구 ASN.1 Playground를 사용하여 이 페이로드를 복원할 수 있습니다. 복원 시 먼저 RFC2251에서 LDAP 메시지의 ASN.1 구조 정의를 컴파일하고 로드해야 합니다. GitHub에서 관련 연구자들이 정의한 asn 파일을 직접 사용할 수 있습니다.
이 페이로드는 최상위 클래스의 objectClass의 필수 속성을 쿼리하는 searchRequest 작업의 BER 인코딩임을 알 수 있습니다. 테스트 후, 이 페이로드의 평균 반사 증폭 효율은 약 50배입니다. 그러나 디코딩된 LDAP 메시지를 다시 인코딩하면 BER 인코딩 비트 수가 줄어들고 일부가 누락되는 것을 알 수 있습니다. 공개 페이로드. :
이 인코딩을 사용할 수 있으면 페이로드 길이가 줄어듭니다(LDAP 메시지 끝 부분에 또 다른 x00을 추가해야 함).
원본 Payload의 경우 원본 Payload의 추가 부분( x30x84...)을 확인할 수 있는데 실제로는 LDAP 메시지 응답 메시지이므로 인코딩 시 요청 메시지에 나타나지 않아야 한다고 간주하여 완전히 제거할 수 있습니다( 여기서 스크립트의 원래 작성자가 무엇을 의도했는지는 확실하지 않습니다.) 테스트 캡처 후 개선된 40바이트 페이로드를 사용할 수 있으며 반사 증폭 효율을 평균 약 73배까지 높일 수 있는 것으로 나타났습니다. 이는 UScert에서 공개한 56~70배 데이터와 비교하면 약 18% 증가한 수치입니다. . 현재 공개 채널에서 사용할 수 있습니다. 아직 더 효율적인 페이로드를 찾지 못했습니다.
事实上，要得到最精简的Payload，还是要回到协议本身。从RFC2251中可以看出searchRequest操作共有8个字段，而接收自定义字符输入的字段只有baseObject、filter、attributes三个。在上述40字节Payload基础上，我们能继续做文章的依然是filter字段和attributes字段。
经过构造filter和attributes字段，我们得到了长度为31字节的更为精简的Payload。该Payload能达到均值约89倍的反射放大效率，相比UScert公布的数据又提升了41%，如果以Akamai捕获到的最高反射数据包大小3662字节计算，新的Payload能达到最高118倍的反射放大倍数，这也将刷新目前已知的CLDAP ReDDoS理论放大倍数：
我们在ZoomEye中通过搜索比较发现，存在缺陷的Windows服务器具有特定的banner信息：
0\x84\x00\x00\x00\x10\x02\x01\x01a\x84\x00\x00\x00\x07\n\x01\x00\x04\x00\x04\x00
结合编码中的每一个标志位来看，该banner信息与LDAP服务器bindResponse响应报文编码十分相似，因此推断出现该banner信息的原因，是由于ZoomEye扫描引擎在扫描到存在缺陷的LDAP服务器时服务器做出了一次绑定操作的响应，且告知客户端绑定成功，这也是在客户端searchRequest之前的必要操作：
使用此banner规则在ZoomEye中搜索共有214673条记录，约占所有LDAP服务器总数411527的52.2%：
考虑到不同服务器在不同时间节点上会出现配置上的变动，于是我们以2015、2016、2017这三年作为区分，使用爬虫分别采集前1000条数据对服务器缺陷进行有效性验证。结果如下表所示：
按照得出的占比，可以估算出目前互联网中存在缺陷的服务器总数：
因此我们认为，目前互联网中至少有2万台Windows服务器正处于被利用进行CLDAP ReDDoS攻击的风险之中，当然这仍然依赖于ZoomEye所提供的数据，真实情况可能有更多。同时，我们获取了这3000条数据中153台缺陷服务器的反射数据包，其中最大的数据包长度为3208字节，最小的数据包长度为1918字节，153个数据包平均包长度为2665字节。根据这些捕获到的数据，现阶段CLDAP ReDDoS的反射放大倍数应当处于62~103倍之间，平均反射放大倍数为86倍左右。
下面对CLDAP协议的缺陷及其造成反射放大DDoS攻击的现状进行了介绍，同时对目前已公开的攻击载荷Payload进行了探讨，并进一步探索出更精简的Payload，将CLDAP ReDDoS反射放大倍数从平均50倍提升至86倍，最后借助ZoomEye对互联网中受影响的Windows服务器进行了统计与分析。当前的CLDAP ReDDoS攻击主要是由于Windows服务器活动目录服务缺陷所引起，在防范上首先也应做到对389端口和636端口的限制，即确保端口不外漏或客户端IP白名单机制。
위 내용은 CLDAP 프로토콜 Reflection DDoS 분석 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
