연구원 팀 북경 대학교, 칭화대 학교, 댈러스 텍사스 대학교 공개 된 정보 식별 할 수 있도록 수행 한 작업 "RangeAmp"라는 새로운 종류의 DoS 공격 콘텐츠 전송 네트워크 (CDN)를 통한 트래픽의 증폭을 구성하기 위해 Range HTTP 헤더의 사용을 기반으로합니다.
방법의 본질 문제는 많은 CDN에서 Range 헤더를 처리하는 특성으로 인해, 공격자 대용량 파일에서 바이트를 요청할 수 있음 CDN을 통해 CDN은 대상 서버에서 전체 파일 또는 훨씬 더 큰 데이터 블록을 다운로드합니다. 캐싱을 위해.
CDN에 따르면 이러한 공격 중 트래픽 증폭 정도는 724 ~ 43330 배로 들어오는 CDN 트래픽을 과부하하거나 피해자 사이트에 대한 최종 통신 채널의 대역폭을 줄이는 데 사용할 수 있습니다.
Range 헤더를 통해 클라이언트는 파일의 위치 범위를 결정할 수 있습니다. 전체 파일을 반환하는 대신로드되어야합니다.
예를 들어 클라이언트는 "Range : bytes = 0-1023"을 지정할 수 있으며 서버는 처음 1024 바이트의 데이터 만 전송합니다. 이 기능은 대용량 파일을 다운로드 할 때 수요가 많습니다. 사용자는 다운로드를 일시 중지 한 다음 중단 된 위치에서 계속할 수 있습니다. "bytes = 0-0"을 지정할 때 표준은 파일의 첫 번째 바이트, "bytes = -1"-마지막, "bytes = 1-"-1 바이트에서 파일 끝까지 제공하도록 규정합니다. 하나의 헤더에 여러 범위를 전달할 수 있습니다 (예 : "Range : bytes = 0-1023.8192-10240").
또한, 두 번째 공격 옵션이 제안되었습니다. (이것은 RangeAmp OBR (Overlapping Byte Ranges) 공격이라고합니다., 네트워크 부하를 증가 시키도록 설계되었습니다. 트래픽이 프록시로 사용되는 다른 CDN을 통해 전달되는 경우 (예 : Cloudflare가 프런트 엔드 (FCDN)로 작동하고 Akamai가 백엔드 (BCDN)로 작동하는 경우) 이 방법은 첫 번째 공격과 비슷하지만 CDN 내에서 지역화되어 있으며 다른 CDN을 통해 액세스 할 때 트래픽을 증가시켜 인프라의 부하를 증가시키고 서비스 품질을 낮출 수 있습니다.
공격자가 CDN 범위 요청에 "bytes = 0-, 0-, 0-...", "bytes = 1-, 0-, 0-..."또는 "바이트 =-1024,0-, 0-…«.
요청에 "0-"범위가 많이 포함되어 있습니다. 이는 파일이 처음부터 끝까지 반환됨을 의미합니다. 첫 번째 CDN이 두 번째를 참조 할 때 잘못된 범위 구문 분석으로 인해 원래 제출 된 공격 요청에 범위 중복 및 교차가 존재하는 경우 전체 파일이 각 "0-"대역 (범위가 집계되지 않고 순차적으로 정렬 됨)으로 반환됩니다. 이러한 공격에서 트래픽 증폭 정도는 53 배에서 7432 배까지 다양합니다.
이 연구에서는 Akamai, Alibaba Cloud, Azure, CDN13, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath, Tencent Cloud 등 77 개 CDN의 동작을 조사했습니다.
연구팀은 "불행히도 여러 번 이메일을 보내고 고객 서비스에 연락을 시도했지만 StackPath는 피드백을 제공하지 않았습니다."라고 말했습니다.
“전반적으로 우리는 책임감있게 취약성을보고하고 완화 솔루션을 제공하기 위해 최선을 다했습니다. 관련 CDN 제공 업체는이 문서가 게시되기 전에 완화 기술을 구현하는 데 거의 XNUMX 개월이 걸렸습니다. "
검토 된 모든 CDN은 대상 서버에 대한 첫 번째 유형의 공격을 허용했습니다.. 두 번째 버전의 CDN 공격은 6 개의 서비스에 노출되었으며, 그중 77 개는 공격에서 인터페이스 역할을 할 수 있으며 (CDNXNUMX, CDNsun, Cloudflare 및 StackPath), XNUMX 개는 백엔드 역할 (Akamai, Azure) 및 StackPath).
Akamai 및 StackPath에서 가장 높은 이득을 얻었으며 순위 제목에 10 개 이상의 순위를 표시 할 수 있습니다.
CDN 소유자에게 알림이 전송되었습니다. 취약점 약 7 개월 전 정보 공개 시점에 CDN 12 개 중 13 개가 확인 된 문제를 해결했거나 문제를 해결할 의지를 표명했습니다.
출처 : https://www.liubaojun.org