데이터 전송 프로토콜 중 하나인 HTTP/2는, 그 자체로는 크게 문제가 없으나 실제 네트워크 환경에서 구현될 때 취약한 방식으로 되기 때문에 문제가 된다. 이를 조사한 연구원은 ‘다운그레이드 하지 않고 HTTP/2를 종단간 방식으로 구현하면 된다’고 강조한다.
[보안뉴스 문가용 기자] HTTP/2을 구현하는 과정에서 꽤나 많은 취약점이 발생하고, 이 때문에 수많은 웹사이트들이 위험에 노출되어 있는 상태라는 연구 결과가 이번 주 개최된 보안 행사 블랙햇(Black Hat)에서 발표됐다. 보안 업체 포트스위거(PortSwigger)의 연구 책임자인 제임스 케틀(James Kettle)이 발표를 맡았다.
케틀은 강연을 통해 자신이 넷플릭스와 같은 유명 사이트들을 HTTP/2 구현 취약점을 통해 공략할 수 있었다고 소개하며 “아마존의 애플리케이션 로드 밸런서와 임퍼바(Imperva)의 클라우드 웹 애플리케이션 방화벽을 사용하는 웹사이트들이 특히 취약하다”고 주장했다. “이런 사이트들의 서버들로 들어가는 요청들을 제 서버로 우회시킬 수 있었습니다.”
HTTP/2는 H2라고도 하는 프로토콜로, 2015년 처음 발표됐다. 지금은 전 세계 모든 웹사이트들의 50%가 HTTP/2를 사용하고 있는 상태다. HTTP/2는 이전 버전인 HTTP/1.1보다 빠르고 간편한 것으로 알려져 있다. 케틀은 HTTP/2에 대해 “데이터가 어떤 형태로 구성되고, 어떤 방식으로 클라이언트와 서버 사이를 오가는지 정의한다”고 설명한다. 또한 “이러한 과정 전체를 클라이언트와 서버 모두에서 관리할 수 있으며 뒷단의 복잡한 내용들은 애플리케이션들에 노출시키지 않는다”고 덧붙였다.
하지만 HTTP/2를 ‘종단간’의 방식으로 활용하지 않을 경우 다양한 보안 문제가 야기될 수 있다. “주로 조직들에서는 프론트엔드 서버가 HTTP/2 프로토콜로 클라이언트들에 데이터를 전송하도록 하고, 클라이언트가 서버에 요청을 보낼 때는 HTTP/1.1을 쓰도록 구현하고 있습니다. 정확히는 클라이언트의 요청을 HTTP/1.1 프로토콜로 재작성 해서 백엔드 서버에 보내고 있죠. HTTP/2로 구현된 것 같지만 사실상 백엔드와 HTTP/1로 통신하는 겁니다.”
케틀은 “말도 안 된다고 코웃음 치는 분들이 많으실 거 같은데, 실제로 이런 설정을 유지하는 조직이 비현실적으로 많다”고 강조한다. “예를 들어 아마존의 애플리케이션 로드 밸런서(Application Load Balancer)의 경우 이런 식의 통신 방법을 해제할 수 없습니다. 이렇게 HTTP/2를 구현할 경우 공격자는 이른 바 디싱크(Desync) 공격을 할 수 있게 됩니다.”
HTTP 디싱크 공격이란, “간단히 설명해 백엔드 서버들이 프론트엔드 서버, 로드 밸런서, 프록시 서버에서 들어오는 연속적인 요청들을 접수해 처리하는 방식에 기인한 취약점을 악용하는 것을 말한다”고 케틀은 설명한다. “예를 프론트서버는 HTTP/2로 데이터를 교환합니다. 그러니 HTTP/2가 지정하는 포맷과 길이로 데이터를 만들어 백엔드 서버로 보내죠. 그런데 백엔드는 HTTP/1.1로 구성되어 있다면, 이 데이터를 이해하지 못합니다. 이 부분에서 충돌이 생기는데, 이를 공격적으로 악용할 수 있습니다.”
그는 이러한 공격이 가능하다는 걸 증명하기 위해 넷플릭스의 웹사이트를 침해하는 실험을 진행했다고 한다. 넷플릭스의 프론트엔드 서버는 HTTP 프로토콜을 다운그레이드 시키는 방식으로 백엔드 서버와 통신하고 있었다고 한다. 그렇기 때문에 데이터의 길이가 잘 맞지 않는 일이 발생했고, 케틀은 익스플로잇을 개발해 이 지점을 공략했다. 넷플릭스의 백엔드가 프론트엔드로부터 들어온 요청을 케틀의 서버로 자동으로 전송하도록 한 것이다.
물론 실험이었으니까 여기까지만 공격을 성공시켰지만, 케틀이 공격을 더 진행했다면 넷플릭스 백엔드 서버에서 악성 코드를 실행하고, 사용자 비밀번호와 신용카드 정보를 훔칠 수 있었을 것이라고 한다. 케틀은 이러한 익스플로잇 가능 사실을 넷플릭스 측에 알렸고, 넷플릭스는 케틀에 2만 달러의 상금을 제공했다. 현재 이 취약점은 해결된 상태다.
또 케틀은 아마존의 애플리케이션 로드 밸런서에서도 HTTP/2가 잘못 구현되어 있는 것을 발견할 수 있었다고 한다. 특정 메시지 헤더 정보가 HTTP/1.1 방식으로 요청의 길이를 추정하고 있었고, 이를 통해 프론트엔드 서버로부터 들어오는 요청을 자신의 서버로 우회시키는 데 다시 한 번 성공할 수 있었다고 한다. 이를 연구하다가 한 사법 기관의 포털이 이러한 취약점에 노출되어 있는 걸 발견했다고 잠깐 언급하기도 했다.
케틀은 “아마존 로드 밸런서를 사용하는 거의 모든 웹사이트들이 이 취약점에 노출되어 있을 것”이라고 덧붙였다. 임퍼바의 WAF에서도 비슷한 특징들과 위험들이 발견됐다고 한다. 케틀은 조직들이 HTTP/2와 관련된 취약점을 네트워크에서 탐지할 수 있게 도와주는 도구인 HTTP 리퀘스트 스머글러(HTTP Request Smuggler)를 발표하기도 했다. 이 툴은 깃허브(https://github.com/portswigger/http-request-smuggler) 페이지에서 열람 및 다운로드가 가능하다.
케틀은 “HTTP/2의 가장 큰 문제는 사용자 조직들이 HTTP/2를 일부 구간에서 다운그레이드하고 있다는 것”이라며 “제발 다운그레이드 하지 말라”고 강조했다. “처음부터 끝까지 HTTP/2를 유지하면 문제가 생기지 않습니다. 물론 100% 방어가 되지는 않을 겁니다만 HTTP/1.1을 혼합해 사용하는 것보다는 훨씬 안전할 겁니다.”
3줄 요약
1. HTTP의 최신 버전인 HTTP/2, 구현 단계에서 취약한 부분 발생됨.
2. 특히 HTTP/2와 HTTP/1.1을 혼합해 사용하고 있다는 게 가장 큰 문제.
3. 네트워크가 이런 부분을 탐지할 수 있게 해 주는 무료 도구가 현재 깃허브에 발표됨.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] HTTP/2을 구현하는 과정에서 꽤나 많은 취약점이 발생하고, 이 때문에 수많은 웹사이트들이 위험에 노출되어 있는 상태라는 연구 결과가 이번 주 개최된 보안 행사 블랙햇(Black Hat)에서 발표됐다. 보안 업체 포트스위거(PortSwigger)의 연구 책임자인 제임스 케틀(James Kettle)이 발표를 맡았다.
[이미지 = utoimage]
케틀은 강연을 통해 자신이 넷플릭스와 같은 유명 사이트들을 HTTP/2 구현 취약점을 통해 공략할 수 있었다고 소개하며 “아마존의 애플리케이션 로드 밸런서와 임퍼바(Imperva)의 클라우드 웹 애플리케이션 방화벽을 사용하는 웹사이트들이 특히 취약하다”고 주장했다. “이런 사이트들의 서버들로 들어가는 요청들을 제 서버로 우회시킬 수 있었습니다.”
HTTP/2는 H2라고도 하는 프로토콜로, 2015년 처음 발표됐다. 지금은 전 세계 모든 웹사이트들의 50%가 HTTP/2를 사용하고 있는 상태다. HTTP/2는 이전 버전인 HTTP/1.1보다 빠르고 간편한 것으로 알려져 있다. 케틀은 HTTP/2에 대해 “데이터가 어떤 형태로 구성되고, 어떤 방식으로 클라이언트와 서버 사이를 오가는지 정의한다”고 설명한다. 또한 “이러한 과정 전체를 클라이언트와 서버 모두에서 관리할 수 있으며 뒷단의 복잡한 내용들은 애플리케이션들에 노출시키지 않는다”고 덧붙였다.
하지만 HTTP/2를 ‘종단간’의 방식으로 활용하지 않을 경우 다양한 보안 문제가 야기될 수 있다. “주로 조직들에서는 프론트엔드 서버가 HTTP/2 프로토콜로 클라이언트들에 데이터를 전송하도록 하고, 클라이언트가 서버에 요청을 보낼 때는 HTTP/1.1을 쓰도록 구현하고 있습니다. 정확히는 클라이언트의 요청을 HTTP/1.1 프로토콜로 재작성 해서 백엔드 서버에 보내고 있죠. HTTP/2로 구현된 것 같지만 사실상 백엔드와 HTTP/1로 통신하는 겁니다.”
케틀은 “말도 안 된다고 코웃음 치는 분들이 많으실 거 같은데, 실제로 이런 설정을 유지하는 조직이 비현실적으로 많다”고 강조한다. “예를 들어 아마존의 애플리케이션 로드 밸런서(Application Load Balancer)의 경우 이런 식의 통신 방법을 해제할 수 없습니다. 이렇게 HTTP/2를 구현할 경우 공격자는 이른 바 디싱크(Desync) 공격을 할 수 있게 됩니다.”
HTTP 디싱크 공격이란, “간단히 설명해 백엔드 서버들이 프론트엔드 서버, 로드 밸런서, 프록시 서버에서 들어오는 연속적인 요청들을 접수해 처리하는 방식에 기인한 취약점을 악용하는 것을 말한다”고 케틀은 설명한다. “예를 프론트서버는 HTTP/2로 데이터를 교환합니다. 그러니 HTTP/2가 지정하는 포맷과 길이로 데이터를 만들어 백엔드 서버로 보내죠. 그런데 백엔드는 HTTP/1.1로 구성되어 있다면, 이 데이터를 이해하지 못합니다. 이 부분에서 충돌이 생기는데, 이를 공격적으로 악용할 수 있습니다.”
그는 이러한 공격이 가능하다는 걸 증명하기 위해 넷플릭스의 웹사이트를 침해하는 실험을 진행했다고 한다. 넷플릭스의 프론트엔드 서버는 HTTP 프로토콜을 다운그레이드 시키는 방식으로 백엔드 서버와 통신하고 있었다고 한다. 그렇기 때문에 데이터의 길이가 잘 맞지 않는 일이 발생했고, 케틀은 익스플로잇을 개발해 이 지점을 공략했다. 넷플릭스의 백엔드가 프론트엔드로부터 들어온 요청을 케틀의 서버로 자동으로 전송하도록 한 것이다.
물론 실험이었으니까 여기까지만 공격을 성공시켰지만, 케틀이 공격을 더 진행했다면 넷플릭스 백엔드 서버에서 악성 코드를 실행하고, 사용자 비밀번호와 신용카드 정보를 훔칠 수 있었을 것이라고 한다. 케틀은 이러한 익스플로잇 가능 사실을 넷플릭스 측에 알렸고, 넷플릭스는 케틀에 2만 달러의 상금을 제공했다. 현재 이 취약점은 해결된 상태다.
또 케틀은 아마존의 애플리케이션 로드 밸런서에서도 HTTP/2가 잘못 구현되어 있는 것을 발견할 수 있었다고 한다. 특정 메시지 헤더 정보가 HTTP/1.1 방식으로 요청의 길이를 추정하고 있었고, 이를 통해 프론트엔드 서버로부터 들어오는 요청을 자신의 서버로 우회시키는 데 다시 한 번 성공할 수 있었다고 한다. 이를 연구하다가 한 사법 기관의 포털이 이러한 취약점에 노출되어 있는 걸 발견했다고 잠깐 언급하기도 했다.
케틀은 “아마존 로드 밸런서를 사용하는 거의 모든 웹사이트들이 이 취약점에 노출되어 있을 것”이라고 덧붙였다. 임퍼바의 WAF에서도 비슷한 특징들과 위험들이 발견됐다고 한다. 케틀은 조직들이 HTTP/2와 관련된 취약점을 네트워크에서 탐지할 수 있게 도와주는 도구인 HTTP 리퀘스트 스머글러(HTTP Request Smuggler)를 발표하기도 했다. 이 툴은 깃허브(https://github.com/portswigger/http-request-smuggler) 페이지에서 열람 및 다운로드가 가능하다.
케틀은 “HTTP/2의 가장 큰 문제는 사용자 조직들이 HTTP/2를 일부 구간에서 다운그레이드하고 있다는 것”이라며 “제발 다운그레이드 하지 말라”고 강조했다. “처음부터 끝까지 HTTP/2를 유지하면 문제가 생기지 않습니다. 물론 100% 방어가 되지는 않을 겁니다만 HTTP/1.1을 혼합해 사용하는 것보다는 훨씬 안전할 겁니다.”
3줄 요약
1. HTTP의 최신 버전인 HTTP/2, 구현 단계에서 취약한 부분 발생됨.
2. 특히 HTTP/2와 HTTP/1.1을 혼합해 사용하고 있다는 게 가장 큰 문제.
3. 네트워크가 이런 부분을 탐지할 수 있게 해 주는 무료 도구가 현재 깃허브에 발표됨.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2025-04-07] 
(0).jpg){kind=spacer}
