보안정보
전문화된 보안 관련 자료, 보안 트렌드를 엿볼 수 있는
차세대 통합보안관리 기업 이글루코퍼레이션 보안정보입니다.
Web Cache Deception 공격 기법
2022.01.05
31,661
01. 개요
코로나19로 인해 비즈니스 패러다임이 온택트 환경으로 전환되면서 고용량 데이터 및 트래픽을 유발하는 서비스가 급격하게 증가되었다. 데이터나 트래픽의 증가는 서비스 품질(QoS, Quality of Service)에 직접적인 영향을 미치기 때문에 다수의 콘텐츠 서비스 제공자들은 CDN(Content Delivery Network)을 통해 다수의 노드(웹 캐시)를 가진 네트워크에 데이터를 저장하여 네트워크 성능 및 비용, 응답속도 향상 등을 도모하고 있다.
사용자에게 제공되는 콘텐츠 유형은 △ 정적 콘텐츠(Static Content)와 △ 동적 콘텐츠(Dynamic Content)로 구분된다. 정적 콘텐츠는 PNG, CSS, JS 등으로 사용자에게 제공되는 정보가 고정된 콘텐츠를 의미하고, 동적 콘텐츠는 JSP, PHP, ASP 등 상호작용을 통해 사용자에 따라 제공되는 정보가 다른 콘텐츠를 의미한다. 앞서 설명한 CDN은 Cashing, Load Balancing, Streaming 등의 기능을 바탕으로 정적 콘텐츠를 보다 빠르게 제공하기 위해 원본 콘텐츠가 저장되어 있는 서버가 아닌 사용자 근거리에 위치한 CDN서버에서 캐시된 콘텐츠를 제공한다. 이로써 사용자는 최적의 경로에 있는 서버를 통해 웹 사이트 콘텐츠, 동영상, 오디오 스트림 등 다양한 콘텐츠를 보다 빠르게 서비스 받을 수 있게 된다.
CDN에서 사용되는 웹 캐시(Web Cache)는 서버의 부하를 줄이고 브라우저 성능을 향상하기 위해 고안된 기술 중 하나이다. 사용자(Client)가 웹 사이트(Server)내 정적 콘텐츠에 접근하는 경우 브라우저에서 해당 콘텐츠를 로컬환경에 저장하여 사용자가 해당 정적 콘텐츠에 재접근 시도 시에는 재요청 과정 없이 로컬에 저장된 콘텐츠를 응답하기 때문에 서버부하 감소 및 응답시간 단축의 효과를 누릴 수 있다.
웹 캐시는 저장위치에 따라 △ 클라이언트 측 캐시(Client side cache)와 △ 서버 측 캐시 (Server side cache)로 분류할 수 있다. 클라이언트 측 캐시는 브라우저 사용자의 로컬환경에 콘텐츠가 저장되는 브라우저 캐시를 포함한 개념으로 클라이언트 측에서 캐시한다. 서버측 캐시는 사용자가 요청한 메시지를 서버에 저장하여 서버내에서 콘텐츠를 캐시하는 기법이다.
웹 캐시 활용한 대표적인 공격으로 Web Cache Poisoning이 알려진 반면, Web Cache Deception대한 위험성을 인지하고 있는 경우가 드물어 이번 호에서는 서버 측 캐시에서 발생할 수 있는 Web Cache Deception 공격기법과 대응방안에 대해서 살펴보고자 한다.
02. Web Cache Deception 관련 기술 설명
1) Reverse Proxy Server
리버스 프록시 서버(Reverse Proxy Server)는 백엔드 서버(Back-End Server) 의 부하를 줄이는 △로드 밸런싱, △웹 가속, △보안 및 익명성을 제공한다. 기본적으로 사용자와 백엔드 서버 사이에 구성되며, 사용자 앞에 위치하는 포워드 프록시(Forward Proxy)와 다르게 백엔드 서버 앞에 위치하여 네트워크에서 전달되는 요청에 대한 중개자 역할을 한다.
[그림 1] Reverse Proxy Server 구성도
2) Proxy Caching
사용자와 백엔드 서버 간의 게이트웨이 역할을 하는 프록시 서버에서 정적 콘텐츠의 복사본을 저장(캐시)한다. 사용자가 리소스에 접근하려고 하면 프록시가 콘텐츠의 최신 복사본을 보유하고 있는지 확인한 후 보유하고 있을 경우 백엔드 서버에 요청을 보내지 않고 사용자에게 최신 복사본을 전달한다. 최신 복사본이 없을 경우 백엔드 서버에 요청 후 응답 받은 메시지를 사용자에게 전달한다.
3) URL Rewrite
URL 재작성(Rewrite)은 간결하고 가독성을 높이는 URL 형태로 변경할 수 있도록 웹 서버에서 제공하는 기능이다. 정규 표현식을 사용하여 각 서버 별 설정 파일에서 설정할 수 있다.
|
일반 URL |
|
|
재작성 URL |
[표 1] URL Rewrite 적용 예시
4) Path Confusion
URL의 경로 혼란(Path Confusion)은 PHP나 URL 재작성에 의해서 발생한다. PHP의 경우 URL의 .php 확장자 뒤에 오는 경로를 허용하고 실제 서버에서는 php 확장자가 존재하는 경로까지 응답한다. URL 재작성도 규칙을 광범위하게 지정할 경우 원래 허용하려던 범위보다 더 넓은 범위의 경로를 허용하게 되어 한 URL 내에 두 개의 확장자를 가지도록 만든다. 실제 서버에서 인식하는 경로는 URL 재작성 규칙에 따라 상이하다.
|
경로 혼란 URL |
|
|
서버가 응답하는 파일 |
[표 2] Path Confusion 예시
03. 공격 기법 상세 분석
1) 공격 기법 소개
Web Cache Deception공격은 리버스 프록시 서버에서 정적 콘텐츠를 캐시하는 인프라의 백엔드 서버에 취약한 URL 재작성 규칙을 적용할 경우 발생한다. [표 3]의 URL 재작성 설정은 nginx 웹 서버의 URL 재작성 설정 방법으로 /home/{파일명}/ 을 요청할 경우 /home/{파일명}.php 와 연결한다. 이때 URL 재작성 규칙을 광범위하게 적용할 경우 /{존재하는 파일 경로}/{존재하지 않는 파일명} 구조의 Web Cache Deception공격을 받을 위험이 있다.
|
URL 재작성 규칙 |
접근 URL |
매칭되는 경로 |
응답하는 페이지 |
|
rewrite ^(/home/.*)/$ /$1.php last; |
/home/main/ |
/home/main/ |
/home/main.php |
|
/home/main/attack.css |
매칭되지 않음 |
404 에러 |
|
|
rewrite ^(/home/.*)/.*$ /$1.php last; |
/home/main/ |
/home/main/ |
/home/main.php |
|
/home/main/attack.css |
/home/main/attack.css |
/home/main.php |
[표 3] URL 재작성 규칙 별 서버의 해석
URL 재작성 규칙을 광범위하게 적용한 서버에 [그림 2]와 같이 정적 콘텐츠로 위장한 동적 콘텐츠 URL로 접근할 경우 요청 파일 확장자가 정적 콘텐츠(CSS)이기 때문에 리버스 프록시 서버는 캐시된 콘텐츠인지 확인한다. 해당 콘텐츠의 최신 복사본이 존재하지 않을 경우 백엔드 서버에 요청을 전달한다.
백엔드 서버에서는 URL 재작성 규칙에 따라 /home/main.php 에 대한 응답을 리버스 프록시 서버로 보내게 되고 응답을 받은 리버스 프록시 서버는 해당 응답을 캐시하게 된다. 이후 [그림 2] URL로 접근하는 모든 사용자는 캐시된 응답을 받게 된다.
[그림 2] Web Cache Deception 공격 Payload
2) 공격 시나리오
[그림 3]은 Web Cache Deception 공격 시나리오 구성도이다. Victim이 정적 콘텐츠로 위장한 동적 콘텐츠에 접근하고 백엔드 서버는 URL 재작성 규칙에 따라 중요정보가 담긴 동적 컨텐츠를 응답한다. 리버스 프록시 서버는 백엔드 서버로부터 전달된 응답을 정적 콘텐츠로 인식하여 서버에 의해 캐시되고 Hacker는 동일한 콘텐츠에 접근하여 캐시된 응답을 얻는다. Web Cache Deception 공격방식은 [그림 3]의 공격시나리오를 통해 차근차근 상세하게 분석해보고자 한다.
[그림 3] Web Cache Deception 공격 시나리오 구성도
3) 공격 시나리오 시연
|
구분 |
IP |
서버 버전 |
OS 버전 |
|
Reverse Proxy Server |
192.168.188.150 |
Nginx/1.18.0 |
Ubuntu 20.04.2 LTS |
|
Back-End Server |
192.168.188.151 |
[표 4] 시연 환경
[그림 4]의 웹 사이트는 URL 재작성이 적용된 웹 페이지로 백엔드 서버 앞에 리버스 프록시 서버가 존재한다. 동적 콘텐츠가 매핑된 URL에 접근할 경우 정적 콘텐츠가 아니기 때문에 HTTP 헤더에서 캐시가 적용되지 않은 것을 확인할 수 있다.
[그림 4] URL 재작성 설정된 웹 서버
[그림 5] 캐시가 적용되지 않은 응답 헤더
정적 콘텐츠로 위장한 동적 콘텐츠 URL에 접근할 경우 CSS 확장자로 인해 리버스 프록시 서버는 해당 콘텐츠가 캐시되어 있는지 확인한다. 해당 콘텐츠는 캐시이 되어있지 않기 때문에 백엔드 서버에 전달하게 되고 백엔드 서버는 URL 재작성 규칙에 따라 동적 콘텐츠 /home/main.php 에 대한 응답을 보낸다. 리버스 프록시 서버는 백엔드 서버로부터 전달받은 응답에 X-Proxy-Cache 헤더와 MISS 값을 추가하며, /home/main/attack.css 콘텐츠를 캐시한다.
[그림 6] 공격 URL에 대한 첫 요청 흐름도
[그림 7] 공격 URL 요청에 대한 응답 헤더
[그림 8] 캐시된 콘텐츠
캐시된 콘텐츠에 다시 한 번 접근할 경우 리버스 프록시 서버는 내부 디스크에서 캐시 여부를 확인 후 백엔드 서버에 요청을 보내지 않고 캐시된 정보를 응답으로 보낸다. X-Proxy-Cache 헤더에 HIT 값을 통해 캐시된 내용이 응답 값으로 온 것을 확인할 수 있다.
[그림 9] 공격 URL에 대한 두 번째 요청 흐름도
[그림 10] 캐시된 정보가 전달된 응답 헤더
사용자가 요청한 동적 페이지가 캐시되어 백엔드 서버까지 도달하지 않는다는 것은 캐시된 페이지 접근에 대해 세션 검증이 이루어지지 않는다는 것을 의미한다. [그림 11]은 사용자의 중요 정보가 담긴 웹 페이지이다. 해당 웹 페이지는 세션을 통해 사용자를 식별하고 식별된 사용자의 정보를 출력하는 페이지다.
[그림 11] 사용자의 중요 정보가 담긴 웹 페이지
[그림 12] mypage.php에 구현된 session 검증 로직
중요 정보가 담긴 동적 콘텐츠를 정적 콘텐츠로 위장한 경로에 사용자가 접근하도록 유도하여 리버스 프록시 서버에서 해당 콘텐츠가 캐시된다. [그림 14]는 사용자의 중요정보가 담긴 페이지가 캐시되어 서버에 저장된 것을 확인할 수 있다.
[그림 13] Web Cache Deception 공격에 취약한 URL로 접근
[그림 14] Reverse Proxy Server에 캐시된 사용자의 중요정보
다른 사용자 또는 세션이 존재하지 않는 사용자조차 캐시된 콘텐츠에 접근할 경우 누군가의 중요정보가 담긴 페이지를 확인할 수 있게 된다.
[그림 15] 다른 사용자로 로그인
[그림 16] 실제 사용자의 마이페이지(좌)와 Web Cache Deception 공격으로 캐시된 페이지(우)
04. 대응방안
Web Cache Deception은 서버의 구성에 따라 △ 비정상적인 URL 리다이렉트, △ 경로 혼란을 차단하는 URL 재작성 규칙 설정, △ Content type별 캐시 △ 캐시된 파일 모니터링을 통해 위험을 완화하거나 조치할 수 있다. Web Cache Deception을 대응하기 위한 대응방안은 서버종류, 캐시방식, URL 재작성 위치 등에 따라 대응방안이 상이하기 때문에 아래 명시된 대응방안을 토대로 운영환경을 고려한 대응전략이 필요하다.
1) 비정상적인 URL 리다이렉트
PHP는 웹 서버로 Apache를 사용할 경우 www.example.com/test.php/test.css와 같이 php 확장자 뒤에 추가 경로가 존재하는 비정상 URL에 대해 제한하지 않는다. Nginx의 경우 에러 페이지로 리다이렉트하여 비정상적인 URL을 제한하고 있다. 각 서버별 설정 파일에서 URL 패턴을 매칭시켜 에러페이지를 출력하도록 설정 가능하기 때문에 비정상적인 URL은 404나 304와 같은 에러 페이지로 리다이렉션 해야 한다. [그림 17]의 location 설정은 재작성 규칙이 설정된 경로에 확장자가 존재하는 파일명을 매핑하여 404 에러페이지를 반환한다. location 설정은 위치나 문법에 따라 우선순위가 달라지기 때문에 시스템영향도를 고려하여 설정해야 한다.
[그림 17] Nginx의 비정상적인 URL 매핑을 통한 에러페이지 출력 예시 (설정파일 경로 : /etc/nginx/site-available/default)
2) 경로 혼란을 차단하는 URL 재작성 규칙 설정
모든 웹 서버의 기본 설정은 URL 재작성 기능을 비활성화하고 있다. 만약 URL 재작성 기능을 사용할 경우 동적 콘텐츠를 정적 콘텐츠로 인식하는 경로 혼란이 발생하지 않도록 광범위한 URL 재작성 규칙설정을 최소화 해야 한다. 주로 패턴의 마지막에 와일드 카드를 사용하는 것처럼 정상 파일 경로 뒤에 추가 경로를 덧 붙일 수 있는 패턴을 사용할 경우 경로 혼란을 야기할 수 있기 때문에 사용에 주의가 필요하다.
|
구분 |
설정 상세 |
|
잘못된 URL 재작성 규칙 |
rewrite ^(/home/.*)/.*$ /$1.php last; |
|
올바른 URL 재작성 규칙 |
rewrite ^(/home/.*)/$ /$1.php last; |
[표 5] Nginx의 URL 재작성 규칙 설정 예시
3) Content type 별 캐시
Web Cache Deception공격을 통해 동적 콘텐츠를 정적 콘텐츠로 인식이 가능하기 때문에 콘텐츠 타입에 따른 보안대책이 필요하다. 정적 콘텐츠와 동적 콘텐츠는 콘텐츠 타입으로 구별이 용이하므로 웹 서버 설정파일에서 콘텐츠 타입으로 제어하는 기능을 지원할 경우 파일 확장자별로 캐시 하지 않고 콘텐츠 타입별로 캐시하는 방식을 사용해야한다.
Apache의 http.conf 파일에서는 mod_expires 모듈을 사용해 콘텐츠 타입별 만료시간을 지정할 수 있다. 캐시하지 않을 콘텐츠는 만료시간을 지정하지 않고 캐시할 콘텐츠는 만료시간을 지정해서 서버에 해당 기간동안 만료되지 않도록 캐시 할 수 있다. 각 콘텐츠 종류별로 연 단위 부터 초 단위까지 만료시간을 지정할 수 있기 때문에 서비스 유형에 따른 만료시간 설정이 필요하다.
|
문서 종류 |
콘텐츠 타입 |
|
php |
text/html |
|
html |
text/html |
|
png |
image/png |
|
javascript |
application/js |
|
css |
text/css |
[표 6] 대표적인 문서 종류별 콘텐츠 타입
|
구분 |
설정 상세 |
|
전체 콘텐츠 설정 |
ExpiresDefault "access plus 2 hours" |
|
콘텐츠 타입별 설정 |
ExpiresByType text/css "access plus 1 years" |
[표 7] Apache에서 캐시 헤더를 설정하는 모듈 (mod_expires)
4) 캐시된 파일 모니터링
다수의 IT인프라를 운영하는 환경에서는 웹서버의 설정사항을 개별적으로 관리하는 것은 자칫 오류를 유발하거나 관리효율이 저하되기 때문에 CDN공급자에게 순수하게 파일이름 기반으로 캐시를 요구하는 방식의 기술적 조치를 적용하기 어려운 경우가 많다. 이러한 경우에는 캐시된 내용에 콘텐츠 경로가 명시되기 때문에 정적 콘텐츠를 사용자가 지정한 경로에만 모아두고 캐시된 콘텐츠를 주기적으로 모니터링하여 캐시된 데이터로 인한 정보유출 등의 피해여부를 확인해야 한다.
05. 결론
지금까지 Web Cache Deception 원리 및 대응방안에 대해서 알아보았다. Web Cache 기능은 한 번 캐시된 콘텐츠에 대해서 사용자는 빠른 응답을 받을 수 있고 서버는 부하가 줄어든다는 장점에 반해, Web Cache Deception과 같이 중요정보가 캐시서버에 저장되고 동일 콘텐츠에 접근한 타 사용자가 해당 정보에 접근할 수 있는 문제를 야기할 수 있다.
시나리오처럼 여러 노드를 가진 분산된 캐시서버가 아닌 단일 캐시서버로 구성될 경우 캐시서버를 특정할 수 있기 때문에 공격이 용이하지만, CDN과 같은 분산된 캐시 서버를 사용하는 경우 Web Cache Deception 공격에 노출될 확률이 낮아지게 된다. Web Cache Deception 공격이 성공하기 위해서 공격자는 피해자가 민감 정보에 접근한 캐시 서버와 동일한 서버에 접근해야 한다.
따라서 CDN의 명확한 이해와 사이트 운영자의 인프라 이해가 없으면 정확한 캐시 상호작용을 추정하기는 어렵다. 마찬가지 이유로 웹 사이트 운영자 관점에서 취약점 점검을 위해 블랙박스 테스팅을 진행하더라도 취약점을 발견하기 어렵기 때문에 웹 사이트가 오랜 기간동안 위험에 노출될 가능성이 높다.
여전히 엔드포인트 사용자나 웹 브라우저는 Web Cache Deception 공격을 감지하거나 보호할 수 있는 메커니즘이 존재하지 않기 때문에 CDN 제공업체의 지침강화로 대응하거나 서버 도메인별 지식이 있는 운영자가 화이트박스 테스팅을 통해 취약점을 식별해야 한다. 따라서 사이트 운영자는 구축 단계부터 CDN의 캐시 및 트래픽 조작을 위한 메커니즘을 고려하여 신중하게 어플리케이션을 설계해야 한다.
06. 참고자료
[1] 웹 캐시
https://ko.wikipedia.org/wiki/웹_캐시
[2] URL 재작성
https://www.iis.net/downloads/microsoft/url-rewrite
[3] Reverse Proxy Server
https://www.imperva.com/learn/performance/reverse-proxy/
[3] Proxy Cache
https://blog.stackpath.com/proxy-caching/
[4] Web Cache Deception
https://www.blackhat.com/docs/us-17/wednesday/us-17-Gil-Web-Cache-Deception-Attack.pdf
[5] Content type별 캐시 설정 방법
https://httpd.apache.org/docs/current/mod/mod_expires.html
[6] 정규 표현식
https://developer.mozilla.org/ko/docs/Web/JavaScript/Guide/Regular_Expressions
[7] Nginx location별 우선순위
https://stackoverflow.com/questions/5238377/nginx-location-priority
[8] Nginx location별 우선순위
https://portswigger.net/daily-swig/path-confusion-web-cache-deception-threatens-user-information-online
