Cache Poisoning and Cache Deception
Last updated
Last updated
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
Trickest를 사용하여 세계에서 가장 진보된 커뮤니티 도구로 구동되는 워크플로우를 쉽게 구축하고 자동화하세요. 오늘 바로 접근하세요:
웹 캐시 오염과 웹 캐시 기만의 차이점은 무엇인가요?
웹 캐시 오염에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하며, 이 콘텐츠는 캐시에서 다른 애플리케이션 사용자에게 제공됩니다.
웹 캐시 기만에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하며, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
캐시 오염은 클라이언트 측 캐시를 조작하여 클라이언트가 예상치 못한, 부분적이거나 공격자가 제어하는 리소스를 로드하도록 강제하는 것을 목표로 합니다. 영향의 정도는 영향을 받는 페이지의 인기 여부에 따라 달라지며, 오염된 응답은 캐시 오염 기간 동안 페이지를 방문하는 사용자에게만 제공됩니다.
캐시 오염 공격의 실행에는 여러 단계가 포함됩니다:
키가 없는 입력 식별: 요청이 캐시되기 위해 필요하지 않지만 서버가 반환하는 응답을 변경할 수 있는 매개변수입니다. 이러한 입력을 식별하는 것은 캐시를 조작하는 데 악용될 수 있으므로 중요합니다.
키가 없는 입력 악용: 키가 없는 입력을 식별한 후, 다음 단계는 이러한 매개변수를 잘못 사용하여 서버의 응답을 공격자에게 유리하게 수정하는 방법을 파악하는 것입니다.
오염된 응답이 캐시되도록 보장: 마지막 단계는 조작된 응답이 캐시에 저장되도록 보장하는 것입니다. 이렇게 하면 캐시가 오염된 동안 영향을 받는 페이지에 접근하는 모든 사용자가 오염된 응답을 받게 됩니다.
일반적으로 응답이 캐시에 저장되었을 때 이를 나타내는 헤더가 있을 것입니다, 이 게시물에서 주의해야 할 헤더를 확인할 수 있습니다: HTTP 캐시 헤더.
응답이 캐시에 저장되고 있다고 생각되면, 잘못된 헤더로 요청을 보내는 것을 시도해 볼 수 있으며, 이 경우 상태 코드 400으로 응답해야 합니다. 그런 다음 요청을 정상적으로 접근해 보고 응답이 400 상태 코드인 경우, 취약하다는 것을 알 수 있습니다(DoS를 수행할 수도 있습니다).
더 많은 옵션은 다음에서 찾을 수 있습니다:
Cache Poisoning to DoS그러나 때때로 이러한 종류의 상태 코드는 캐시되지 않기 때문에 이 테스트가 신뢰할 수 없을 수 있습니다.
Param Miner를 사용하여 응답을 변경할 수 있는 매개변수와 헤더를 브루트 포스할 수 있습니다. 예를 들어, 페이지가 클라이언트가 그곳에서 스크립트를 로드하도록 지시하기 위해 X-Forwarded-For 헤더를 사용할 수 있습니다:
매개변수/헤더가 확인되면 어떻게 정화되고 어디서 반영되거나 헤더의 응답에 영향을 미치는지 확인하십시오. 이를 악용할 수 있는 방법이 있습니까? (XSS를 수행하거나 당신이 제어하는 JS 코드를 로드할 수 있습니까? DoS를 수행할 수 있습니까?...)
악용할 수 있는 페이지를 식별하고 사용할 매개변수/헤더와 악용하는 방법을 파악한 후, 페이지를 캐시해야 합니다. 캐시에 가져오려는 리소스에 따라 시간이 걸릴 수 있으며, 몇 초 동안 시도해야 할 수도 있습니다.
응답의 헤더 **X-Cache**는 요청이 캐시되지 않았을 때 miss 값을 가질 수 있고, 캐시되었을 때는 hit 값을 가질 수 있으므로 매우 유용할 수 있습니다.
헤더 **Cache-Control**은 리소스가 캐시되고 있는지, 다음에 리소스가 다시 캐시될 시간은 언제인지 아는 데 흥미롭습니다: Cache-Control: public, max-age=1800
또 다른 흥미로운 헤더는 **Vary**입니다. 이 헤더는 일반적으로 키가 없는 추가 헤더를 캐시 키의 일부로 처리하기 위해 사용됩니다. 따라서 사용자가 목표로 하는 피해자의 User-Agent를 알고 있다면, 특정 User-Agent를 사용하는 사용자들을 위해 캐시를 오염시킬 수 있습니다.
캐시와 관련된 또 다른 헤더는 **Age**입니다. 이는 객체가 프록시 캐시에 있는 시간을 초 단위로 정의합니다.
요청을 캐시할 때는 사용하는 헤더에 주의해야 합니다. 일부 헤더는 예상치 않게 키가 있는 것으로 사용될 수 있으며, 피해자는 동일한 헤더를 사용해야 합니다. 항상 다양한 브라우저로 캐시 오염을 테스트하여 작동하는지 확인하십시오.
헤더 X-Forwarded-For가 정화되지 않고 응답에 반영되고 있습니다.
기본 XSS 페이로드를 보내고 캐시를 오염시켜 페이지에 접근하는 모든 사람이 XSS에 노출되도록 할 수 있습니다:
이것은 /en이 아닌 /en?region=uk에 대한 요청을 오염시킬 것입니다.
쿠키는 페이지의 응답에 반영될 수도 있습니다. 예를 들어, 이를 악용하여 XSS를 유발할 수 있다면, 악성 캐시 응답을 로드하는 여러 클라이언트에서 XSS를 악용할 수 있을 것입니다.
Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.
Check:
Cache Poisoning via URL discrepancies이 글에서는 https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123와 같은 URL로 OpenAI API 키를 훔칠 수 있었던 방법을 설명합니다. /share/*와 일치하는 모든 것이 Cloudflare가 URL을 정규화하지 않고 캐시되기 때문에 가능했습니다. 이는 요청이 웹 서버에 도달했을 때 수행되었습니다.
이것은 다음에서 더 잘 설명됩니다:
Cache Poisoning via URL discrepancies때때로 캐시를 악용하기 위해 여러 개의 키가 없는 입력을 악용해야 할 필요가 있습니다. 예를 들어, X-Forwarded-Host를 귀하가 제어하는 도메인으로 설정하고 X-Forwarded-Scheme을 http로 설정하면 Open redirect를 찾을 수 있습니다. 서버가 모든 HTTP 요청을 HTTPS로 전달하고 X-Forwarded-Scheme 헤더를 리디렉션의 도메인 이름으로 사용하는 경우, 리디렉션에 의해 페이지가 가리키는 위치를 제어할 수 있습니다.
Vary 헤더로 악용하기X-Host 헤더가 JS 리소스를 로드하는 도메인 이름으로 사용되고 있지만, 응답의 Vary 헤더가 **User-Agent**를 나타내고 있다면, 피해자의 User-Agent를 유출하고 해당 User-Agent를 사용하여 캐시를 오염시킬 방법을 찾아야 합니다:
URL와 본문에 요청을 포함한 GET 요청을 보냅니다. 웹 서버가 본문에서 가져온 것을 사용하지만 캐시 서버가 URL에서 가져온 것을 캐시하는 경우, 해당 URL에 접근하는 모든 사용자는 실제로 본문에서 가져온 매개변수를 사용하게 됩니다. James Kettle이 Github 웹사이트에서 발견한 취약점과 같습니다:
There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get
예를 들어, parameters를 ruby 서버에서 ; 문자를 사용하여 & 대신 구분할 수 있습니다. 이를 사용하여 키가 없는 매개변수 값을 키가 있는 매개변수 안에 넣고 악용할 수 있습니다.
Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking
여기에서 HTTP Request Smuggling을 악용하여 Cache Poisoning 공격을 수행하는 방법에 대해 알아보세요.
Web Cache Vulnerability Scanner는 웹 캐시 오염을 자동으로 테스트하는 데 사용할 수 있습니다. 다양한 기술을 지원하며 매우 사용자 정의가 가능합니다.
Example usage: wcvs -u example.com
ATS는 URL 내의 fragment를 제거하지 않고 전달했으며, 호스트, 경로 및 쿼리만 사용하여 캐시 키를 생성했습니다(프래그먼트는 무시됨). 따라서 요청 /#/../?r=javascript:alert(1)은 백엔드에 /#/../?r=javascript:alert(1)로 전송되었고, 캐시 키에는 페이로드가 포함되지 않았습니다. 오직 호스트, 경로 및 쿼리만 포함되었습니다.
content-type 헤더에 잘못된 값을 보내면 405 캐시 응답이 발생했습니다. 캐시 키에는 쿠키가 포함되어 있어 인증되지 않은 사용자만 공격할 수 있었습니다.
GitLab은 정적 콘텐츠를 저장하기 위해 GCP 버킷을 사용합니다. GCP Buckets는 **헤더 x-http-method-override**를 지원합니다. 따라서 헤더 x-http-method-override: HEAD를 보내고 캐시를 오염시켜 빈 응답 본문을 반환하도록 할 수 있었습니다. 또한 PURGE 메서드를 지원할 수 있었습니다.
Ruby on Rails 애플리케이션에서는 Rack 미들웨어가 자주 사용됩니다. Rack 코드의 목적은 x-forwarded-scheme 헤더의 값을 가져와 요청의 스킴으로 설정하는 것입니다. 헤더 x-forwarded-scheme: http가 전송되면 동일한 위치로 301 리디렉션이 발생하여 해당 리소스에 대한 서비스 거부(DoS)를 유발할 수 있습니다. 또한 애플리케이션은 X-forwarded-host 헤더를 인식하고 사용자를 지정된 호스트로 리디렉션할 수 있습니다. 이 동작은 공격자의 서버에서 JavaScript 파일을 로드하게 하여 보안 위험을 초래할 수 있습니다.
Cloudflare는 이전에 403 응답을 캐시했습니다. 잘못된 Authorization 헤더로 S3 또는 Azure Storage Blobs에 접근하려고 하면 403 응답이 캐시되었습니다. Cloudflare는 403 응답 캐싱을 중단했지만, 이 동작은 다른 프록시 서비스에서도 여전히 존재할 수 있습니다.
캐시는 종종 캐시 키에 특정 GET 매개변수를 포함합니다. 예를 들어, Fastly의 Varnish는 요청에서 size 매개변수를 캐시했습니다. 그러나 잘못된 값으로 URL 인코딩된 매개변수(예: siz%65)가 함께 전송되면 캐시 키는 올바른 size 매개변수를 사용하여 구성됩니다. 그러나 백엔드는 URL 인코딩된 매개변수의 값을 처리합니다. 두 번째 size 매개변수를 URL 인코딩하면 캐시에서 생략되지만 백엔드에서 사용됩니다. 이 매개변수에 0 값을 할당하면 캐시 가능한 400 Bad Request 오류가 발생합니다.
일부 개발자는 서버 부하를 관리하기 위해 FFUF 또는 Nuclei와 같은 고트래픽 도구의 사용자 에이전트와 일치하는 요청을 차단합니다. 아이러니하게도, 이 접근 방식은 캐시 오염 및 DoS와 같은 취약점을 도입할 수 있습니다.
RFC7230는 헤더 이름에서 허용되는 문자를 지정합니다. 지정된 tchar 범위를 벗어난 문자가 포함된 헤더는 이상적으로 400 Bad Request 응답을 유발해야 합니다. 그러나 실제로 서버는 항상 이 표준을 준수하지 않습니다. 주목할 만한 예는 Akamai로, 유효하지 않은 문자가 포함된 헤더를 전달하고 cache-control 헤더가 없으면 400 오류를 캐시합니다. \와 같은 불법 문자가 포함된 헤더를 보내면 캐시 가능한 400 Bad Request 오류가 발생하는 패턴이 발견되었습니다.
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Cache Deception의 목표는 클라이언트가 민감한 정보로 저장될 리소스를 로드하게 만드는 것입니다.
우선, extensions인 .css, .js, .png 등이 일반적으로 캐시에 저장되도록 구성되어 있다는 점에 유의하세요. 따라서 www.example.com/profile.php/nonexistent.js에 접근하면 캐시는 .js extension을 보고 응답을 저장할 가능성이 높습니다. 그러나 application이 _www.example.com/profile.php_에 저장된 민감한 사용자 콘텐츠로 replaying하는 경우, 다른 사용자로부터 해당 콘텐츠를 훔칠 수 있습니다.
테스트할 다른 사항들:
www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
덜 알려진 확장자 사용하기:.avif
또한, 이 글에서 매우 명확한 예를 찾을 수 있습니다: https://hackerone.com/reports/593712. 예제에서는 _http://www.example.com/home.php/non-existent.css_와 같은 존재하지 않는 페이지를 로드하면 http://www.example.com/home.php (사용자의 민감한 정보 포함)의 내용이 반환되고 캐시 서버가 결과를 저장한다고 설명합니다. 그런 다음 attacker는 자신의 브라우저에서 _http://www.example.com/home.php/non-existent.css_에 접근하여 이전에 접근한 사용자의 기밀 정보를 관찰할 수 있습니다.
cache proxy는 파일의 확장자(css)를 기반으로 캐시하도록 구성되어야 하며, 콘텐츠 유형에 따라 캐시되지 않아야 합니다. 예제 _http://www.example.com/home.php/non-existent.css_는 text/css MIME 유형 대신 text/html 콘텐츠 유형을 가집니다(이는 .css 파일에 대한 예상입니다).
여기에서 HTTP Request Smuggling을 악용하여 Cache Deceptions 공격을 수행하는 방법에 대해 알아보세요.
toxicache: URL 목록에서 웹 캐시 오염 취약점을 찾고 여러 주입 기술을 테스트하는 Golang 스캐너입니다.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
