꼰머의 보안공부

1. BIND (Berkeley Internet Name Domain) [1]

- DNS를 구현한 오픈소스 소프트웨어 [2]

2. 주요내용

- CISA는 BIND 9 DNS 소프트웨어 제품군에서 발견된 여러 취약점에 대한 권고 발표 [3]

> ISC에 의해 발견되어 패치가 적용됨

> 공격자들은 이를 악용해 DoS 공격을 실행할 수 있음

2.1 CVE-2024-4076 [4][5]

- DNS 서버에서 오래된 데이터와 로컬 데이터 조회가 동시에 이루어질 때 발생하는 오류(Assertion 실패)가 서비스 거부 상태를 유발

> Assertion: BIND 서버가 특정 조건이나 상태를 확인하고, 맞지 않을 경우 오류 발생 또는 특정 동작을 수행하는 것

영향받는 버전
- BIND 9
> 9.16.13 ~ 9.16.50
> 9.18.0 ~ 9.18.27
> 9.19.0 ~ 9.19.24

- BIND Supported Preview Edition
> 9.11.33-S1 ~ 9.11.37-S1
> 9.16.13-S1 ~ 9.16.50-S1
> 9.18.11-S1 ~ 9.18.27-S1

2.2 CVE-2024-1975 [6][7]

- KEY 레코드를 처리하거나 캐시된 레코드를 검증할 때, SIG(0) 서명된 요청을 연속적으로 전송하여 CPU 리소스를 소진(과도한 부하)시켜 서비스 거부 상태를 유발

> 서버가 KEY Resource Record가 포함된 영역을 호스팅하거나, DNSSEC이 KEY Resource Record를 캐시의 DNSSEC 서명 도메인에서 유효성을 확인하는 경우

> KEY Resource Record(DNSKEY 레코드): DNSSEC 서명을 확인하는 데 사용되는 공개 키가 포함되어 있으며, 이를 이용해 무결성을 검증 [8]

> SIG(0) 서명: DNSSEC에서 DNSKEY 레코드의 무결성을 보장하기 위해 사용되는 디지털 서명(즉, DNSKEY 레코드에 대한 디지털 서명)

> 클라이언트는 서버로부터 DNSKEY 레코드와 SIG(0) 서명을 받아 DNSKEY 레코드에서 공개키 추출 및 해당 공개키를 사용해 SIG(0)의 서명의 유효성 검증

영향받는 버전
- BIND 9
> 9.0.0 ~ 9.11.37
> 9.16.0 ~ 9.16.50
> 9.18.0 ~ 9.18.27
> 9.19.0 ~ 9.19.24

- BIND Supported Preview Edition
> 9.9.3-S1 ~ 9.11.37-S1
> 9.16.8-S1 ~ 9.16.49-S1
> 9.18.11-S1 ~ 9.18.27-S1

2.3 CVE-2024-1737 [9][10]

- 서버가 동일한 호스트에 대해 많은 수의 Resource Records(RR)를 보유하고 있는 경우 데이터베이스의 성능 저하를 유발

> DB에 RR 내용 추가나 업데이트 또는 클라이언트의 쿼리 처리 시 성능 저하가 발생할 수 있음

> 질의 속도가 100배 느려질 수 있음

영향받는 버전
- BIND 9
> 9.11.0 ~ 9.11.37
> 9.16.0 ~ 9.16.50
> 9.18.0 ~ 9.18.27
> 9.19.0 ~ 9.19.24

- BIND Supported Preview Edition
> 9.11.4-S1 ~ 9.11.37-S1
> 9.16.8-S1 ~ 9.16.50-S1
> 9.18.11-S1 ~ 9.18.27-S1

2.4 CVE-2024-0760 [11][12]

- TCP를 통해 다수의 DNS 메시지를 보내 서버 과부하 또는 다운을 발생시켜 서비스 거부 유발

> ACL을 사용해도 공격이 완화되지 않음

영향받는 버전
- BIND 9
> 9.18.1 ~ 9.18.27
> 9.19.0 ~ 9.19.24

- BIND Supported Preview Edition
> 9.18.11-S1 ~ 9.18.27-S1

3. 대응방안

- 최신 보안 업데이트 적용 [13][14]

※ CVE-2024-1975의 경우 serve-stale(만료된 콘텐츠를 클라이언트에 제공하는 것) 비활성화 시 완화 가능한 것으로 보임

4. 참고

[1] https://www.isc.org/bind/
[2] https://github.com/isc-projects/bind9?tab=readme-ov-file
[3] https://www.cisa.gov/news-events/alerts/2024/07/24/isc-releases-security-advisories-bind-9
[4] https://nvd.nist.gov/vuln/detail/CVE-2024-4076
[5] https://kb.isc.org/v1/docs/cve-2024-4076
[6] https://nvd.nist.gov/vuln/detail/CVE-2024-1975
[7] https://kb.isc.org/v1/docs/cve-2024-1975
[8] https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dnskey-ds-records/
[9] https://nvd.nist.gov/vuln/detail/CVE-2024-1737
[10] https://kb.isc.org/v1/docs/cve-2024-1737
[11] https://nvd.nist.gov/vuln/detail/CVE-2024-0760
[12] https://kb.isc.org/v1/docs/cve-2024-0760
[13] https://kb.isc.org/docs/aa-00913
[14] https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&pageIndex=1&nttId=71506&menuNo=205020
[15] https://www.dailysecu.com/news/articleView.html?idxno=158092
[16] https://m.boannews.com/html/detail.html?idx=131717&skind=5
[17] https://asec.ahnlab.com/ko/79800/

1. 개요

- DNS 서버의 핵심적 열할 때문에 항상 주요 공격 표적이 됨 [1]
> 23년 한 보고서에 따르면 DNS 서버를 대상으로 한 DDoS 공격은 22년 대비 약 4배 증가 [2]
- 과거 DNS 서버 대상 위협이 확인되지 않던 과거와 달리 최근 국내 DNS 서버를 대상으로 한 공격이 식별 및 증가 추세
> 24년 초를 기점으로 유입되었던 소량의 이상 트래픽은 점차 증가
> DNS 서버가 짧은 기간 동안 지속적이면서도 반복적인 대량의 NXDomain 응답 반환 식별

2. 주요내용

2.1 DNS

- Domain Name Service: 도메인 네임(www[.]example[.]com)과 IP 주소(1.1.1[.]1)를 서로 변환하는 역할

> DNS Client는 DNS Resolver에게 도메인 네임의 IP 주소를 요청

> DNS Resolver는 Root 네임 서버, TLD(Top-Level Domain) 네임 서버, Authoritative 네임 서버에 질의를 전송 및 응답

2.2 NXDomain (Non-eXistent Domain)

- 질의한 도메인 네임이 존재하지 않을 때 응답 값

2.3 DDoS

2.3.1 NXDomain Flooding (Nonsense Name Attack)

- 2015년에 처음 알려진 공격 유형

- 존재하지 않는 도메인 질의를 요청할 시 권한(Authoritative) 네임 서버가 불필요한 자원을 소모한다는 점을 착안

> IP를 위•변조하여 존재하지 않는 도메인에 대한 다량의 질의를 통해 요청을 처리하는 DNS 서버의 자원을 소모시켜 서비스 거부 상황을 초래

※ 단순히 대상 DNS 서버의 자원을 소모시키는 목적을 지니므로 요청에 대한 응답을 받을 필요가 없으므로 IP 위•변조 가능

2.3.2 Sub-Domain Scan Attack

- Sub-Domain: 주 도메인에 추가된 하위 도메인

> 서로 다른 별도의 기능을 가진 웹사이트를 구분하여 운영하기 위해 사용

- 해당 공격은 공격자가 대상 도메인의 하위 도메인을 검색하여 네트워크 구조 파악 및 잠재적인 취약점을 찾기 위함

> 다양한 서브 도메인을 질의하여 존재 여부 확인을 목적으로 하며, 존재하지 않는 서브 도메인의 경우 NXDomain 응답

> 보호되지 않은 자원을 발견하거나 공격할 수 있는 새로운 경로를 찾는 것이 목적

※ DNSCewl(서로 다른 문자열을 조합하여 공격에 사용 가능한 새로운 문자열 생성하는 도구), haklistgen(외부 홈페이지를 스캔하여 서브 도메인, HTTP Response 페이로드에서 공격에 활용할 수 있는 문자열을 추출하는 도구) 등의 Tool 사용 [5][6]

※ 질의한 서브 도메인이 실제 존재하는지를 확인해야 하므로 IP 위•변조 불가

3. 대응

- NSDomain Flooding은 과도한 응답을 유발시키는 것이 목적

> Response Rate Limiting (RRL)를 통해 NXDomain에대한 질의를 제한 (nxdomains-per-second: 초당 NXDOMAIN 응답 수 제한) [7]

> L7 레벨에서 DNS서버의 NXDomain 응답 임계치를 설정하고, 임계치 이상의 응답이 있을 경우 해당 출발지 IP를 임시(or 영구) 차단

- Sub-Domain Scan은 취약하거나 새로운 공격 표면을 찾기 위한 목적

> 취약한 도메인이 외부에서 접속 가능한 상태로 운용되지 않도록 조치

> 또한, 조직 내부적으로 지속적인 공격 표면 관리(ASM, Attack Surface Management)를 통해 공격 표면을 줄이고 잠재적 위협을 사전에 차단해 보안 강화 필요

공격 표면 관리(ASM, Attack Surface Management)
> 조직이 소유 및 운영하는 모든 자산을 지속적으로 모니터링
> 잠재적인 취약점 식별 및 이에 대한 대응 조치를 취하는 보안 전략
> 모든 서브 도메인과 경로를 포함한 전체 자산을 명확히 파악할 수 있으며, 내부 자산에 대한 가시성 확보 가능
> 노출된 공격 표면을 최소화하고 발견된 취약점을 신속히 조치함으로써 잠재적 공격 벡터를 줄일 수 있음

4. 참고

[1] https://www.fsec.or.kr/bbs/detail?menuNo=244&bbsNo=11509

[2] https://www.radware.com/security/threat-advisories-and-attack-reports/escalating-trends-in-dns-flood-attacks/

[3] https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

[4] https://www.networkworld.com/article/934916/a-new-kind-of-ddos-threat-the-nonsense-name-attack.html

[5] https://github.com/codingo/DNSCewl

[6] https://github.com/hakluke/haklistgen

[7] https://www.manageengine.com/dns-dhcp-ipam/help/response-rate-limiting-rrl-in-ddi.html

1. 개요

- 독일 아테네국립응용사이버보안연구센터에서 DNS 보안 프로토콜 DNSSEC의 설계 결함을 악용한 KeyTrap (CVE-2023-50387) 발견 [1]
- 단일 DNS 패킷을 전송하여 서비스 거부를 유발할 수 있음
> 취약한 DNS의 경우 최소 170초에서 최대 16시간 동안 서비스 거부 발생

2. 주요내용

2.1 DNSSEC(Domain Name System Security Extension) [2][3]

- DNS는 도메인(hxxps://example[.]com)을 IP 주소(1.1.1.1)로 변환하는 역할
> 초기 설계시 보안성을 충분히 고려하지 못해 DNS 정보 위-변조가 가능하다는 문제 존재 Ex. DNS Cache Poisoning

- 기존 DNS 보안성을 강화하기 위해 공개키 암호화 방식의 보안기능을 추가한 DNSSEC(DNS Security Extensions) 도입
> DNS를 대체하는 것이 아님

2.2 KeyTrap(CVE-2023-50387) [4]

- DNSSEC 설계 결함으로 인해 DNS 서버에 서비스 거부를 유발할 수 있는 취약점
> DNSKEY 및 RRSIG 레코드가 여러개일 경우 프로토콜 사양에 따라 모든 조합에 대한 유효성 검사를 수행

- 취약점과 관련된 세 가지 DNSSEC 설계 문제
① 여러 개의 서로 다른 DNS 키가 동일한 키 태그를 가질 수 있어 서명 유효성 검사 프로세스에 계산 부하 발생 가능
② 서명을 성공적으로 검증하는 키를 찾거나 모든 키가 시도될 때까지 모든 키를 시도해야 하므로(가용성 보장 목적) 계산 부하 발생 가능
③ 동일한 레코드에 여러 서명이 있는 경우 유효한 서명을 찾거나 모든 서명이 시도될 때까지 수신된 모든 서명을 검증해야 하므로, 계산 부하 발생 가능

- 영향받는 버전

2.2.1 SigJam (하나의 키 X 다수 서명)

- DNS Resolve가 하나의 DNS 키를 사용하여 DNS 레코드에 존재하는 다수의 유효하지 않은 서명을 검증하도록 유도
> DNS Resolve가 DNSKEY로 검증할 수 있는 서명을 찾을 때까지 모든 서명을 시도하도록 설계 됨
> 공격자는 단일 DNS 응답에 340개의 서명을 작성할 수 있음
> 340개의 서명에 대한 유효성 검증을 수행한 후 DNS Reolve는 클라이언트에 SERVFAIL를 반환

2.2.2 LockCram (다수의 키 X 하나의 서명)

- DNS Resolve가 ZSK DNSSEC키를 사용하여 DNS 레코드를 통해 하나의 서명을 검증하도록 유도
> DNS Resolve가 하나의 키가 검증되거나 모두 시도될 때까지 서명에 사용할 수 있는 모든 키를 시도하도록 설계 됨
> DNS Resolve는 서명을 검증하기 위해 모든 DNSSEC 키를 사용
> 해당 서명이 유효하지 않다고 결론을 내릴 때까지 서명이 참조하는 모든 키를 시도

2.2.3 KeySigTrap (다수의 키 X 다수의 서명)

- SigJam과 LockCram를 결합하여 검증 과정이 2배 증가하는 공격

> 모든 키와 서명 쌍이 검증될 때까지, 가능한 모든 조합에 대해 검증을 시도

Ex. 첫 번째 ZSK를 사용해 N개 서명을 검증한 후, 두 번째 ZSK를 사용해 N개 서명을 검증하여 N번째 ZSK를 사용해 N개 서명을 검증

> 모든 조합 시도 후 레코드를 검증할 수 없다는 결론을 내리고 클라이언트에 SERVFAIL를 반환

2.2.4 HashTrap (다수의 키 X 다수의 해시)

- 다수의 DS 해시 레코드에 대해 충동하는 다수의 DNSKEY를 검증하기 위해 많은 해시를 계산하도록 유도

3. 대응방안

- 벤더사 제공 패치 제공
> 현재까지 나온 패치는 임시 조치
> DNSSEC 설계를 처음부터 다시 해야 문제가 해결될 것

- DNSSEC 기능 비활성화시 취약점이 근본적으로 사라지나 권장하지 않음
> KeyTrap 취약점을 제외하면 DNSSEC로부터 얻는 안전의 이득이 훨씬 많음

4. 참고

[1] https://www.athene-center.de/en/keytrap
[2] https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/resources/dns/dnssecInfo/dnssecInfo.jsp
[3] https://medium.com/iocscan/how-dnssec-works-9c652257be0
[4] https://nvd.nist.gov/vuln/detail/CVE-2023-50387
[5] https://www.boannews.com/media/view.asp?idx=126791
[6] https://www.boannews.com/media/view.asp?idx=126911

1. Zone Transfer

- Master DNS 서버와 Slave DNS 서버 간 Zone 파일을 동기화하기 위한 프로토콜

- Slave 서버는 Master 서버에 접속하여 Zone 파일을 비교 및 최신화

- Zone Transfer는 TCP 이용

DNS Zone
- 도메인 관리하는 단위를 영역(Zone)이라 함
- 하나의 DNS 서버가 책임이나 권한을 가지는 영역을 의미

2. 실습

DNS  서버
- Domain : test.com
- OS : CentOS7 64bit
- IP : 192.168.56.114

Client 1
- IP : 192.168.56.112

Client 2
- IP : 192.168.56.102

- DNS 서버 구축

※ 아래 두 사이트를 참고하여 구축

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)을 확인해보면, allow-transer {any;};로 설정

- 그 결과, 누구나 Zone Transer 수행 가능

- 다음 명령으로 Zone Transfer 수행

dig @192.168.56.114 axfr test.com

① axfr : 존 버전에 상관없이 무조건 존 전송 요청
② ixfr : 존 버전을 비교하여 상위 버전일 경우 존 전송 요청

- 위 명령 수행 결과 Zone 파일 노출

- 와이어샤크를 통한 패킷 확인

3. 대응

① DNS를 Master/Slave로 운영하지 않는다면, Zone Tranfer를 사용하지 않도록 설정

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)에 allow-transfer 옵션을 수정 

- Client 1과 2에서 Zone Transfer 수행 결과 Transfer failed 출력

- 와이어샤크를 통한 패킷 확인

② Zone Transfer를 운영해야 할 경우 Slave를 특정하여 운영

- DNS 서버의 Zone 파일 (/etc/named.rfc1912.zones)에 allow-transfer 옵션을 수정 

- Client 1만 Zone Transfer가 가능하도록 설정변경

- Client 1과 2에서 Zone Transfer 수행 결과 차이를 통해 비교