HTTP/2 rapid reset _ 신속한 재설정 취약점 [CVE-2023-44487]

CVE-2023-44487 취약점은 최근에 발견된 HTTP/2 프로토콜을 대상으로 하는 DoS 계열 취약점입니다.

 

CVSS 7.5 등급을 평가 받은 취약점이며, 인터넷에 노출된 모든 HTTP/2 엔드포인트에 영향을 미칠 수 있습니다.

 

해당 취약점의 경우, 취약점이 발생만 한다면 웹 서비스에 메인 서비스 장애 등의 파급력을 끼칠 수 있기에,

 

발 빠르게 대처해야 해당 취약점에 대한 피해를 막을 수 있습니다.

 

 

AWS의 대처

 

Microsoft의 대처

 

이와 같이 AWS, Microsoft 등 IT 계열 대기업들이 해당 취약점에 대해 대처하고

 

취약점의 위험성, 발생원리 ,테스트 방법등을 알리는 것을 확인할 수 있습니다.

 

https://github.com/bcdannyboy/CVE-2023-44487

GitHub - bcdannyboy/CVE-2023-44487: Basic vulnerability scanning to see if web servers may be vulnerable to CVE-2023-44487

 

다음과 같은 github 소스코드를 통해 쉽게 취약점을 진단하고 테스트할 수 있습니다.

 

제 개인적인 생각인데, 지금 HTTP/2를 사용해서 서비스하는 웹 서비스는 무수히 많을 것이고,

 

그중에서도 버그바운티를 받고 있는 웹 서비스도 무수히 많을 것인데..

 

해당 취약점은 테스트도 쉽고, 파급력도 크기 때문에 빠르게 서비스들을 대상으로

 

취약점을 탐지해본다면 .. 어쩌면 취약점을 제보할 수 있을지도 모른다고 생각합니다.

 

아무튼 서론은 이정도에서 끊고, 취약점의 원리에 대해 알아보겠습니다.

취약점의 원리와 분석

원리 자체는 어렵지 않은 취약점입니다.

 

HEADERS와 RST_STREAM을 사용하여 설정된 수의 HTTP 요청을 보내고,

 

이 시퀀스를 반복하여 대상 HTTP/2 서버에 트래픽을 과도하게 부여함으로써 서버에 무리가 가도록 합니다.

 

잘 이해가 되지 않을 수 있는데, 차근 차근 설명해보겠습니다.

 

HTTP/2는 엔트포인트 간에 다양한 메시지, 프레임을 전송하는데 사용되는 양방향 추상화인 '스트림'을 이용합니다.

 

HTTP/2에서는 '스트림 멀티플렉스'를 활용하여 TCP 연결의 활용도를 높입니다. 일반적으로 스트림은

 

하나의 TCP연결만을 사용하며 연결 양쪽에서 서로를 추적할 수 있는 방식으로 다중화됩니다.

 

이때 만약 스트림 멀티 플렉싱을 사용하게 되면, 클라이언트가 여러 개별 연결을 관리하지 않고도 여러 개의 진행 중인

 

요청을 할당받을 수 있게 됩니다.

 

 

일반적으로 HTTP/1.1에서는 각각의 요청이 순차적으로 처리됩니다.

 

서버가 요청을 읽고, 처리 후, 응답을 작성하고, 다음 요청을 읽고 처리합니다.

 

이는 곧 단일 연결을 통해 전송될 수 있는 요청 비율이 왕복당 요청 1개임을 의미합니다.

 

이때 왕복에는 네트워크 대기시간, 프록시 처리 시간 및 백엔드 요청 처리 시간 등이 포함됩니다.

 

하지만 HTTP/2를 사용하게 되면, 클라이언트는 단일 TCP 연결에서 동시에 여러 스트림을 열 수 있게 됩니다.

 

이떄 각각의 스트림은 하나의 HTTP 요청에 해당됩니다.

 

이론적으로 최대 동시 오픈 스트림 수를 서버에서 제어할 수 있지만,

 

실제로는 클라이언트가 하나의 연결 당 100개 이상의 스트림을 열 수 있으며, 서버는 이러한 요청을 병렬로 처리하게 됩니다.

 

만약 클라이언트가 100개의 스트림을 보내고 각 스트림에 대해 단일 왕복으로 요청을 보내게 되면,

 

백엔드 서버에서 요청은 병렬화 될 것입니다. 그런 다음 클라이언트는 이전 스트림에 대해 응답을 받으면

 

새 스트림을 열 수 있습니다. 이는 각 연결에 대해 효과적인 처리량을 제공하게 되며,

 

각 연결의 활용도를 100배 이상 높여주게 됩니다.

 

하지만 이러한 장점이 HTTP/2에서 취약점으로 남용되게 되었습니다.

 

HTTP/2에서는 이전 스트림 취소 요청을 RST_STREAM 프레임을 전송함으로써 나타냅니다.

 

프로토콜은 클라이언트와 서버간의 연결이 특정 방식으로 취소를 조정하도록 요구하지 않으며, 클라이언트는

 

일방적으로 요청을 취소할 수 있습니다.

 

이것을 통해 공격이 시행됩니다.

 

공격자는 HTTP/2에서 한번의 많은 수의 스트림을 열어놓고, 서버의 응답을 기다리지 않고

 

클라이언트는 각 요청을 즉시 취소해버립니다. 스트림을 즉시 재설정하는 기능을 사용하게 되면,

 

각 연결이 진행 중인 요청수를 무제한으로 유지하는 것이 가능하게 됩니다.

 

요청을 명시적으로 취소하였기에 공개 스트림 제한 수도 초과하지 않으며, 진행 중인 요청의 수는

 

더 이상 왕복 시간에 좌우되지 않고 사용 가능한 네트워크 대역폭에만 좌우되게 됩니다.

 

일반적으로 HTTP/2 서버에서는 취소된 요청에 대해 새로운 스트림 데이터 구조 할당, 쿼리 구문 분석,

 

헤더 압축 해제 수행, URL 리소스 매핑 등 상당한 양의 작업을 수행하게 됩니다.

 

하지만 클라이언트는 요청을 명시적으로 취소하였기에 거의 자원을 소모하지 않게되고, 이로 인해

 

서버와 클라이언트 간의 이용 가능한 자원 비대칭이 발생하게 됩니다.

 

단일 연결에 여러 HEADERS와 RST_STREAM 프레임을 포함시킴으로써 공격자는

 

초당 요청을 크게 증가시킬 수 있고, 서버의 CPU 사용량은 과도하게 증가하게 됩니다.

 

이것이 HTTP/2 rapid reset, 신속한 재설정 공격의 핵심이자 원리입니다.

 

from 감펩님

 

 

 

결론

HTTP/2에서 발생하는 신속한 재설정 공격은 공격 난이도에 비해 파급력이 크고,

 

HTTP/2 프로토콜을 사용하는 어지간한 웹 서버에는 모두 통용될 수 있는 공격입니다.

 

서비스 무력화까지 영향을 끼칠 수 있는 위험한 취약점이니,

 

다들 원리 파악하시고 잘 대비하시길 바랍니다.

 

Reference : https://msrc.microsoft.com/blog/2023/10/microsoft-response-to-distributed-denial-of-service-ddos-attacks-against-http/2/

Microsoft Response to Distributed Denial of Service (DDoS) Attacks against HTTP/2 | MSRC Blog | Microsoft Security Respo

Reference : https://snyk.io/blog/find-fix-http-2-rapid-reset-zero-day-vulnerability-cve-2023-44487/

from 감펩님

읽어주셔서 감사합니다!

 

오타 및 잘못된 정보는 댓글 또는 디스코드로 알려주시면 감사하겠습니다!

 

디스코드 : one3147