HTTP/2 rapid reset attack 취약점 [CVE-2023-44487], Curl 명령어 를 이용한 확인 방법(설치 포함)

최근 여러 보안팀 업체에서 「HTTP/2 취약점」 점검으로 확인 요청이 들어와 내용을 확인해 보니 다음과 같습니다. 사용자가 엣지「Edge」나 크롬「Chrome」 같은 브라우저를 이용하여 대다수의 일반적인 「HTTP/1(1.1)」서버에 하나의 요청「Request #1」이 들어오면 1:1로 「Response #1」 응답을 합니다. 하지만 네이버나 구글 같은 대형 포털 사이트의 경우는 클라이언트에서 여러 개의 동시 「Request #1-100」 요청 및 「Response #1-100」 응답을 처리하기 위해 최소 「HTTP/2」 서버 서비스를 이용합니다. 하지만 공격자들은 이런 좋은 기능을 악용하여 하나의 클라이언트에서 여러 요청을 무한정으로 요청하여 DDoS의 형태로 공격하는 「Rapid Reset Attack '고속 재설정 공격'」 문제가 발생하고 있다는 내용이었습니다.

HTTP 버전	정상 처리 과정
HTTP1 / HTTP1.1	TCP ▷ SSL/TLS(선택적) ▷ Request #1 요청 ▷ Response #1 응답 ▷ Request #2 요청 ▷ Response #2 응답, 형태로 하나씩 왕복 처리
HTTP2	TCP ▷ TLS 1.2+ ▷ Request #1-100 스트림 요청 ▷ Response #1-100 응답 ▷ Request #101-200 스트림 요청 ▷ Response #101-200 응답, 형태로 하나의 클라이언트에서 동시에 여러개의 스트림 왕복 처리
HTTP3	QUIC + TLS 1.3 동시 처리 (UDP) ▷ QUIC 스트림은 동일 요청 응답내에서 독립적으로 처리

HTTP 버전	공격자 처리 과정
HTTP2	TCP ▷ TLS 1.2+ ▷ Request #1-n 스트림 요청 ▷ 응답이 오기전에 요청 취소, Rapid Reset ▷ Request #2-n 스트림 요청 ▷ 응답이 오기전에 요청 취소, Rapid Reset ▷ 무한 반복, DDoS 형태로 네트워크 인터넷 트래픽을 대량으로 발생 문제는 하나의 클라이언트에서도 대량 시도가 가능하기 때문에, 다수의 취약 좀비 PC를 이용하여 공격이 들어오면 초당 몇 억건도 가능한 TCP 요청이 들어오게 됩니다.

◇ 참고 문서

구글 클라우드 : HTTP/2의 새로운 'Rapid Reset' DDoS 공격

Cloudflare : HTTP/2 Rapid Reset: 기록적인 공격의 분석

KISA 보호나라 : MS 10월 보안 위협에 따른 정기 보안 업데이트 권고 「내용 중 HTTP/2 포함」

 

레드헷「RedHat」 : 요약(기술적 세부 사항) 및 진단 방법

CDNetworks : HTTP/3「QUIC」 기술 문서

---

◈ 진단 방법 ①

레드헷「RedHat」 문서를 확인해 보면 HTTP 버전을 확인하기 위해 「Curl」 명령어를 이용합니다. 이는 특정 서버의 실제 HTTP 프로토콜 버전을 알려준다고 합니다.

 

◇ 예시 http://foxydogtest.co.kr 사이트를 체크

[root@]# curl -sl http://foxydogtest.co.kr -o/dev/nell -w '%{http_version}\n'

1 or 1.1

 

◇ 예시 HTTPS, 특정 포트 10443을 사용하여 가상 서버 192.168.0.1을 체크

[root@]# curl -sl https://192.168.0.1:10443 -o/dev/nell -w '%{http_version}\n'

2

 

「1」 또는 「1.1」을 반환하면 「CVE-2023-44487」 취약점에 영향을 받지 않는다고 합니다. 만약 「2」를 반환하면 취약점에 영향을 받을 수 있으니 시스템 구성을 한번 점검해봐야 합니다. 정확히는 2가 나온다고 해서 무조건 취약하다기보다 DDoS 공격 타깃이 될 수 있으니 미리 소프트웨어를 업그레이드, 동시 HTTP/2 연결 스트림 수를 제한, 앞단 방화벽 IPS를 이용한 IP 제한 및 트래픽 필터링을 이용하여 대비를 할 수도 있습니다.

 

대기업 포털 사이트급 정도의 시스템이 아니라면 대부분의 일반 호스팅은 「1.1」를 사용하고 있어 크게 신경 쓸 일은 없을 것으로 보입니다.

---

◈ 진단 방법 ②

관리자가 아니라 일반 사용자도 엣지「Edge」나 크롬「Chrome」 같은 브라우저를 이용하여 웹에서 직접 확인을 할 수 있습니다.

 

◇ 크롬 브라우저 예시

어떤 브라우저든 사이트 접근 후에 「F12」을 누르면 대부분 개발자 툴을 지원합니다. 그다음 네트워크「Network」 메뉴를 선택합니다. 네트워크 활동 기록 중 상태가 보이면 사이트에 요청을 하거나 「Ctrl+R」을 눌러 새로고침을 합니다.

 

요청 값이 나오면 프로토콜「Protocol」 라인을 확인하면 HTTP 버전을 확인할 수 있습니다. 만약 해당 라인이 보이지 않는다면 기본값은 선택되어 있지 않아 빈 공간 마우스 오른쪽 클릭 후 「헤더 옵션」에서 프로토콜「Protocol」을 선택하면 됩니다.

 

 

 

◇ HTTP/2, HTTP/3 사용 업체 예시

---

◈ Curl 명령어 사용 참고

[root@]# curl -sl http://localhost -o/dev/nell -w '%{http_version}\n'

curl: unknown --write-out variable: 'http_version'  「에러 메시지」

 

[root@]# curl -V  「버전 확인(대문자)」

curl 7.29.0

처음에는 명령어 Unknown 발생해서 확인해 보니 「-w, --write-out <format>」 해당 옵션이 Curl 버전이 몇 이상에서 생긴 거라 버전이 낮아 사용을 못한 부분입니다.

 

◇ Curl 최신 버전 설치

Curl 공식 사이트 저장소 : https://curl.se/download/

 

테스트 환경 「CentOS 7.X」 「Rocky 8.X」

※ Download/curl-x.x.x.tar.gz 뒤에 부분만 원하는 버전으로 설치 하시면 됩니다.

[root@]# wget https://curl.se/download/curl-8.5.0.tar.gz --no-check-certificate    「다운로드」

[root@]# tar -xvf curl-8.5.0.tar.gz    「압축 해제」

 

[root@]# cd curl-8.5.0    「경로 이동」

[root@]# ./configure --with-ssl    「컴파일」

[root@]# make && make install    「Make 설치」

 

[root@]# cp -arp /usr/bin/curl /usr/bin/curl_old    「기존 Curl 백업 시, 하고 싶은 경우만」

[root@]# cp /usr/local/bin/curl /usr/bin/curl    「기존 PATH 경로 Curl 덮어쓰기」

cp: overwrite ‘/usr/bin/curl’? y

 

[root@]# curl -V    「버전 변경 확인」

curl 8.5.0 (x86_64-pc-linux-gnu) libcurl/8.5.0 OpenSSL/1.0.2k-fips zlib/1.2.7
Release-Date: 2023-12-06

 

 

◆ 「Configure」 컴파일 에러 발생 시

해당 에러메시지가 확인된다면 라이브러리 또는 프로그램을 설치하면 됩니다.

checking for ar... no
configure: error: ar not found in PATH. Cannot continue without ar.

 

[root@]# yum「or dnf」 install gcc openssl-devel

config.status: error: in `/root/curl-8.5.0':
config.status: error: Something went wrong bootstrapping makefile fragments
    for automatic dependency tracking. If GNU make was not used, consider
    re-running the configure script with MAKE="gmake" (or whatever is
    necessary). You can also try re-running configure with the
    '--disable-dependency-tracking' option to at least be able to build
    the package (albeit without support for automatic dependency tracking).
See `config.log' for more details

 

[root@]# yum「or dnf」 install make

---

 

항상 올해 말이나 새해 초에 취약점 같은 게 많이 나오는 것 같네요. 이것 말고도 소소하게 많이 있지만 보안 뉴스에서 크리티컬 하게 다루거나 보안팀에서 자주 문의 오는 것만 올리고 있습니다. Apache를 사용하면서 대다수가 HTTP/1.1을 사용하고 있고 동시 접속량이 많은 대기업 포탈은 이미 한참 전에 HTTP/2, HTTP/3을 사용하고 있었다는 것을 알게 되었습니다. 흥미가 있으신 분들은 상단 기술 문서를 보면 좀 더 이해가 될 것으로 보입니다.