꼰머의 보안공부

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. 개요

- 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

1. 개요

- 09.07.07 ~ 07.10 3차례에 걸쳐 국내 주요 기관 및 인터넷 포털 사이트를 대상으로 대규모 DDoS 공격 발생

> 09.07.04 미국 주요 사이트를 대상으로 공격이 시작되어, 09.07.07 국내 대상 공격이 시작됨

- 정부기관, 은행, 포털, 언론, 쇼핑몰 등 26개 주요 인터넷 사이트가 서비스 제공이 불가능

- 공격 이후 경각심을 깨우치고 공격 예방 및 정보보호 생활화를 위해 매년 7월 둘째 수요일을 정보보호의 날로 지정

2. 주요내용

2.1 타임라인

① 웹하드 서버 악성코드 감염

- 미상의 공격자는 웹하드 서비스 업체의 서버에 침입

- 웹하드 프로그램 업데이트 파일에 악성코드를 삽입

② 사용자 웹하드 업데이트

- 사용자는 자동 업데이트 등으로 웹하드 업데이트 진행

- 업데이트 파일에 삽입된 악성코드에 의해 msiexec.exe 파일이 악성코드에 감염

※ msiexec.exe

> 파일 경로: C:\Windows\system32

> Windows에서 사용하는 인스톨러 관련 기능을 담당하는 설치 프로그램

③ C2 서버 접근

- 감염된 사용자 PC는 C2서버 접속 및 DDoS 공격을 위한 파일 다운로드

- 다운로드 파일: msiexec1.exe, msiexec2.exe, msiexec3.exe

※ 각 파일의 동작 과정은 동일하며, 공격 대상 리스트와 DDoS 공격 방식의 차이를 보임

④ 추가 파일 다운로드

- msiexec1.exe은 DDoS 공격을 위한 추가 파일 다운로드

> msiexec2.exe, msiexec3.exe의 경우 uregvs.nls 파일의 내용만을 변경하며 나머지 과정은 동일

⑤ DDoS 공격 수행

- 다운받은 파일을 기반으로 DDoS 수행

> 당시 KISA는 공격이 115,000여개 IP주소에서 공격 트래픽이 발생했다고 발표

- 국내 DDoS 공격 대상

2.2 기존 DDoS와 차이점

※ 당시 발표된 자료를 기반한 정리로 현황가 차이가 있을 수 있음

2.3 당시 사후조치

3. 대응방안

4. 참고

[1] https://teamcrak.tistory.com/110
[2] https://ko.wikipedia.org/wiki/7%C2%B77_DDoS_%EA%B3%B5%EA%B2%A9
[3] https://itwiki.kr/w/7.7_%EB%94%94%EB%8F%84%EC%8A%A4
[4] https://www.boannews.com/media/view.asp?idx=21860
[5] https://www.etnews.com/201209110597

1. BGP (Border Gateway Protocol) [1]

- 서로 다른 AS(autonomous system) 사이에서 사용되는 라우팅 프로토콜

- 179/TCP 사용하여, 유니캐스트 방식으로 라우팅 정보를 전송

- 조직간에 계약된 정책(Policy)에 따라 최적 경로를 결정

- 장애가 발생할 경우 적게는 하나의 국가, 크게는 전 세계의 네트워크에 영향을 미침

> AS 간 라우팅을 수행하며, 수만 개에서 수십만 개 이상의 네트워크가 라우팅 테이블에서 관리되기 때문으로 판단됨.

2. 취약점 [2]

2.1 개요

- FRRouting, BIRD, OpenBGPd, ​​Mikrotik RouterOS, Juniper JunOS, Cisco IOS, Arista EOS 등 7가지 BGP 구현을 분석

> BGP 보안에서 자주 간과되는 소프트웨어 구현의 취약점 발견

> 공격자가 취약한 BGP 피어에 서비스 거부(DoS)를 유발할 수 있는 BGP 메시지 구문 분석 취약점

> 각 취약점은 FRRouting 팀에 전달되었으며 다음 버전에서 수정됨

- BGP 프로토콜 보안과 관련한 많은 연구가 진행

> BGP 피어가 리소스 공개 키 인프라(RPKI)와 같은 인증 및 암호화 메커니즘을 적용

※ RPKI (Resource Public Key Infrastructure): 인터넷주소자원 소유기관 및 IP주소, AS번호 등을 PKI(공개키 기반 암호화)를 기반으로 전자서명 처리하여 해당 라우팅 정보의 무결성을 인증하는 것

> 하지만, 최근 연구에서 BGP가 여전히 안전하지 않다는 것을 보여주고 있음

- 리눅스 및 유닉스용 오픈소스 인터넷 라우팅 프로토콜 FR라우팅(FRRouting) [4] 8.4 버전(22.07 배포)에서 새로운 취약점이 발견

> FR라우팅(FRRouting)은 엔비디아, 덴트, 소닉 등 유명 기업들에서도 사용하는 라우팅 프로토콜

> 해당 취약점들을 신속히 패치하지 않으면 공급망에 큰 영향을 미칠 수 있으며, 공격자는 취약점을 악용해 다음의 행위를 수행할 수 있음

① 모든 BGP 세션 및 라우팅 테이블을 삭제

② 지속적으로 잘못된 패킷을 전송해 BGP 피어를 응답하지 않는 서비스 거부 상태로 유지

※ BGP 데몬은 일정 시간 초과 후 자동으로 재시작함

2.2 CVE-2022-40302

- 취약점의 근본 원인은 BGP OPEN 메시지에서 확장 옵션 길이 옥텟에 대한 불충분한 경계 검사

- line 1: 옵션 길이 옥텟(optlen 변수)을 읽음

> optlen이 0xff(BGP_OPEN_NON_EXT_OPT_LEN 상수로 정의됨)인 경우 stream_getc()를 호출하여 다음 옥텟 (optype) 읽기를 계속 수행

> 확장 옵션 매개 변수를 0xff로 끝나도록 조작된 BGP OPEN 메시지가 수신되면, stream_getc() 호출 시 범위를 벗어난 읽기가 발생하는 것으로 판단됨.

- line 8: 원시 패킷 스트림에서 다음 옥텟 값을 읽음

> optype이 0xff와 동일한 경우 OPEN 패킷에는 RFC 9072(프로토콜 표준 문서)에 따라 확장된 옵션 매개 변수가 포함된 것으로 간주

> 조작된 BGP OPEN 메시지에 의해 범위를 벗어난 읽기가 발생하며, 이로인해 SIGABRT 시그널이 발생하여 FRRouting의 bgpd 데몬이 다시 시작되어 DoS 상태가 발생하는 것으로 판단됨.

※ SIGABRT: 프로세스가 비정상적인 상태에 도달했을 때 강제로 프로세스를 종료하기 위한 시그널

2.3 CVE-2022-40318 // 불확실하므로 추가 공부 필요

- 취약점의 근본 원인은 AS4 기능(RFC 6793에 따른 4바이트 AS 번호)을 읽을 때 OPEN 메시지 패킷에 대한 잘못된 경계 검사

- peek_for_as4_capability()는 AS4의 기능을 찾기위해 구문 분석을 수행하는 함수

> line12: 수신된 옵션의 길이 검증

> 수신된 OPEN 메시지에 길이가 확장된 옵션 매개 변수가 있는 경우(RFC 9072에 따름) 원시 패킷 스트림에서 2바이트 대신 3바이트를 읽음

> 코드가 "while" 루프에서 반복되도록 하여 반복 중 하나에서 범위를 벗어난 읽기를 트리거하는 것으로 판단 됨

2.4 CVE-2022-43681 // 불확실하므로 추가 공부 필요

- bgp_open_option_parse() 함수에서 취약점이 발생

> line6: 정규 옵션 길이를 가진 패킷에 존재해야 하는 2개의 옥텟만 설명하는 경계 검사 수행

> 경계 검사는 총 세 개의 옥텟이 있어야 하는 확장 옵션 길이를 고려하지 못하여 범위를 벗어난 읽기를 트리거

2.3 완화

- BGP는 인터넷의 필수적인 부분이기 때문에 보안에 대한 몇 가지 지침이 있음

> 그러나 이러한 지침은 BGP 보안에 대한 알려진 문제와 RPKI 배포 방법에만 초점을 맞추는 경향이 있음

> 따라서 조직은 BGP 보안을 처리하기 위해 ISP에만 의존해서는 안 됨

- 네트워크 인프라 장치 패치

> 확인된 3개의 취약점과 같은 BGP 구현상 취약점 완화 목적

> 조직의 모든 네트워크 장치와 해당 장치에서 실행 중인 소프트웨어 버전 형상 관리 필요

- Forescout은 Python 기반 오픈 소스 BGP Fuzzer 도구를 제공 [7]

> 조직이 내부적으로 사용되는 BGP 제품군의 보안을 테스트하고 BGP 구현에서 새로운 결함을 찾을 수 있도록하기 위함

3. 참조

[1] https://net-study.club/entry/Routing-Protocol-BGP-Border-Gateway-Protocol
[2] https://www.forescout.com/blog/three-new-bgp-message-parsing-vulnerabilities-disclosed-in-frrouting-software/
[3] https://thehackernews.com/2023/05/researchers-uncover-new-bgp-flaws-in.html
[4] https://github.com/FRRouting/frr
[5] https://github.com/FRRouting/frr/pull/12043
[6] https://github.com/FRRouting/frr/pull/12247
[7] https://github.com/Forescout/bgp_boofuzzer/

- 각 공격방식의 특징에따라 대응 방법이 다르다.

- 일반적으로 대응하는 방식은 다음과 같다.

① DDoS 대응 서비스 가입

- 한국인터넷 진흥원에서 제공하는 사이버 대피소 혹은 클린존 서비스 이용

② 백업 서버 구축

- 디도스 공격에따른 서비스 장애를 최소화하기 위해 백업 서버 구축

③ 공격 대상 노출 최소화

- 공격에 이용 및 대상이 되지않도록 주기적인 점검

④ 서비스 점검

- 불필요한 포트 혹은 서비스를 사용중인지 점검

⑤ 모니터링

- 평시 발생하는 트래픽을 인지하고, 이상 트래픽의 발생 유무 모니터링

- KISA DDoS 공격 대응 가이드 참고

1. DoS (Denial Of Service) 유형

2. DDoS (Distributed Denial of Service) 유형

3. DRDoS (Distributed Reflection Denial of Service) 유형

* 해당 방식 외에도 다양한 방식이 존재하며, 구분한 기준 역시 상대적인 것임.

1. DoS (Denial of Service)

- 정당한 사용자가 서비스를 사용하는 것을 방해하는 행위.

- 대상 시스템의 처리 범위를 초과하는 과도한 트래픽을 전송해 부하를 유발하여 정상 서비스를 제공하지 못하도록 함.

- 단일 공격자가 단일 시스템을 대상으로 공격 진행.

2. DDoS (Distributed Denial of Service)

- DoS와 마찬가지로 대상 시스템의 처리 범위를 초과하는 과도한 트래픽을 전송해 부하를 유발하여 정상 서비스를 제공하지 못하도록 함.

- 취약한 서버에 악성코드를 배포해 좀비 PC로 이루어진 봇넷을 형성한 후 공격.

- 다수의 분산 좀비 PC를 이용해 단일 시스템에 공격 진행.

3. DRDoS (Distributed Reflection Denial of Service)

- 대상 시스템의 처리 범위를 초과하는 과도한 트래픽을 전송해 부하를 유발하여 정상 서비스를 제공하지 못하도록 함.

- 악성코드를 배보하고 봇넷을 형성하는 등의 과정없이 프로토콜의 구조적 취약점을 이용한 공격.

- 해당 프로토콜의 구조적 취약점을 이용해 정상적인 서비스를 제공하는 시스템을 반사체로 이용해 공격 진행.