mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00

History

Translator 43b57d21d9 Translated ['generic-methodologies-and-resources/external-recon-methodol		2024-04-10 13:40:56 +00:00
..
cache-poisoning-to-dos.md	Translated ['generic-methodologies-and-resources/external-recon-methodol	2024-04-10 13:40:56 +00:00
README.md	Translated ['generic-methodologies-and-resources/external-recon-methodol	2024-04-10 13:40:56 +00:00

README.md

캐시 독려 및 캐시 속임수

htARTE (HackTricks AWS Red Team Expert)를 통해 **제로부터 영웅까지 AWS 해킹 배우기**!

HackTricks를 지원하는 다른 방법:

회사가 HackTricks에 광고되길 원하거나 PDF로 HackTricks 다운로드하고 싶다면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구입하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 요령을 공유하세요.

Trickest를 사용하여 세계에서 가장 고급 커뮤니티 도구로 구동되는 워크플로우를 쉽게 구축하고 자동화하세요.
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

차이점

웹 캐시 독려와 웹 캐시 속임수의 차이는 무엇인가요?

웹 캐시 독려에서 공격자는 응용 프로그램에 악성 콘텐츠를 캐시에 저장하도록 유도하고, 이 콘텐츠는 캐시에서 다른 응용 프로그램 사용자에게 제공됩니다.

웹 캐시 속임수에서 공격자는 응용 프로그램에 다른 사용자에게 속한 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 그런 다음 공격자는 이 콘텐츠를 캐시에서 검색합니다.

캐시 독려

캐시 독려은 클라이언트 측 캐시를 조작하여 클라이언트가 예상치 않은, 부분적인 또는 공격자의 통제 하에 있는 리소스를 로드하도록 강제하는 것을 목표로 합니다. 영향의 정도는 영향을 받는 페이지의 인기에 따라 다릅니다. 오염된 캐시 기간 동안 페이지를 방문하는 사용자에게 오염된 응답이 전달됩니다.

캐시 독려 공격의 실행에는 여러 단계가 포함됩니다:

키가 없는 입력 식별: 이러한 입력은 요청이 캐시되는 데 필요하지 않지만 서버가 반환하는 응답을 변경할 수 있는 매개변수입니다. 이러한 입력을 식별하는 것은 캐시를 조작하는 데 중요합니다.
키가 없는 입력의 악용: 키가 없는 입력을 식별한 후, 다음 단계는 이러한 매개변수를 남용하여 공격자에게 이점을 주는 방식으로 서버의 응답을 수정하는 것입니다.
독려된 응답이 캐시에 저장되도록 보장: 마지막 단계는 조작된 응답이 캐시에 저장되도록 하는 것입니다. 이렇게 하면 캐시가 오염된 동안 영향을 받는 페이지에 액세스하는 모든 사용자가 오염된 응답을 받게 됩니다.

발견: HTTP 헤더 확인

일반적으로 응답이 캐시에 저장된 경우 그렇다는 것을 나타내는 헤더가 있습니다. 이 게시물에서 주의를 기울여야 할 헤더를 확인할 수 있습니다: HTTP 캐시 헤더.

발견: 캐시 오류 코드 확인

응답이 캐시에 저장되고 있다고 생각한다면 잘못된 헤더로 요청을 보내어 상태 코드 400으로 응답해야 합니다. 그런 다음 요청을 정상적으로 액세스하고 응답이 400 상태 코드인 경우 취약점을 알 수 있습니다 (심지어 DoS를 수행할 수도 있습니다).

더 많은 옵션을 찾을 수 있습니다:

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

그러나 가끔 이러한 종류의 상태 코드가 캐시되지 않을 수 있으므로 이 테스트가 신뢰할 수 없을 수도 있습니다.

발견: 키가 없는 입력 식별 및 평가

Param Miner를 사용하여 페이지의 응답을 변경할 수 있는 매개변수 및 헤더를 무차별 대입할 수 있습니다. 예를 들어 페이지가 클라이언트가 스크립트를 로드할 위치를 나타내기 위해 X-Forwarded-For 헤더를 사용할 수 있습니다:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

백엔드 서버로부터 유해한 응답 유도

식별된 매개변수/헤더를 확인하여 어떻게 검열되고 있는지, 그것이 어디에서 반영되거나 응답에 어떤 영향을 주는지 확인하십시오. 그것을 어떻게 남용할 수 있을까요 (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를 당하도록 할 수 있습니다:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note that this will poison a request to /en?region=uk not to /en

DoS를 위한 캐시 독려

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

쿠키 처리 취약점을 악용하기 위한 웹 캐시 독려

쿠키는 페이지 응답에 반영될 수도 있습니다. 예를 들어 XSS를 유발할 수 있다면, 악의적인 캐시 응답을로드하는 여러 클라이언트에서 XSS를 악용할 수 있습니다.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

경로 순회를 통한 API 키 도용을 위한 캐시 오염

이 설명은 사용자가 매우 자주 사용하는 취약한 쿠키의 경우 정기적인 요청으로 인해 캐시가 정리될 수 있음을 주의해야 합니다. https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123와 같은 URL로 OpenAI API 키를 도용하는 것이 가능했던 이유를 설명합니다. /share/*와 일치하는 모든 것이 Cloudflare가 URL을 정규화하지 않고 캐시에 저장되기 때문에, 웹 서버에 요청이 도달했을 때 이 작업이 수행되었습니다.

여러 헤더를 사용하여 웹 캐시 오염 취약점 악용

가끔은 여러 키가 없는 입력을 악용하여 캐시를 남용해야 할 수 있습니다. 예를 들어, X-Forwarded-Host를 당신이 제어하는 도메인으로 설정하고 X-Forwarded-Scheme를 http로 설정하면 Open redirect를 찾을 수 있습니다. 만약 서버가 모든 HTTP 요청을 HTTPS로 전달하고 리디렉트를 위해 헤더 X-Forwarded-Scheme을 도메인 이름으로 사용한다면, 리디렉트할 페이지를 제어할 수 있습니다.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

제한된 `Vary` 헤더를 이용한 공격

만약 응답의 Vary 헤더가 **User-Agent**를 나타내지만 X-Host 헤더가 JS 리소스를 로드하는 도메인 이름으로 사용되고 있다면, 피해자의 User-Agent를 유출하고 해당 사용자 에이전트를 사용하여 캐시를 오염시킬 방법을 찾아야 합니다:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

GET 요청을 URL과 본문에 모두 포함하여 보냅니다. 웹 서버가 본문의 것을 사용하고 캐시 서버가 URL의 것을 캐시하는 경우, 해당 URL에 액세스하는 사람은 실제로 본문의 매개변수를 사용하게 됩니다. Github 웹 사이트에서 James Kettle이 발견한 취약점과 유사합니다.

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

파라미터 은폐

예를 들어 루비 서버에서는 & 대신 ; 문자를 사용하여 파라미터를 분리할 수 있습니다. 이를 사용하여 키가 지정된 파라미터 값에 키가 지정되지 않은 값을 넣고 남용할 수 있습니다.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

HTTP 요청 스머글링을 남용하여 HTTP 캐시 독점 공격

여기에서 HTTP 요청 스머글링을 남용하여 캐시 독점 공격을 수행하는 방법에 대해 알아보세요.

웹 캐시 독점을 위한 자동 테스트

웹 캐시 취약점 스캐너를 사용하여 웹 캐시 독점을 자동으로 테스트할 수 있습니다. 다양한 기술을 지원하며 매우 사용자 정의가 가능합니다.

예시 사용법: wcvs -u example.com

Trickest를 사용하여 세계에서 가장 고급 커뮤니티 도구를 활용한 워크플로우를 쉽게 구축하고 자동화하세요.
지금 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

취약한 예시

Apache Traffic Server (CVE-2021-27577)

ATS는 URL 내의 fragment를 제거하지 않고 전달하고 캐시 키를 호스트, 경로 및 쿼리만 사용하여 생성했습니다 (fragment는 무시). 따라서 요청 /#/../?r=javascript:alert(1)가 백엔드로 /#/../?r=javascript:alert(1)로 전송되었고 캐시 키에는 페이로드가 포함되지 않았으며 호스트, 경로 및 쿼리만 포함되었습니다.

GitHub CP-DoS

콘텐츠 유형 헤더에 잘못된 값이 전송되면 405 캐시 응답이 트리거됩니다. 캐시 키에 쿠키가 포함되어 있기 때문에 인증되지 않은 사용자만 공격할 수 있습니다.

GitLab + GCP CP-DoS

GitLab은 정적 콘텐츠를 저장하기 위해 GCP 버킷을 사용합니다. GCP 버킷은 **헤더 x-http-method-override**를 지원합니다. 따라서 헤더 x-http-method-override: HEAD를 보내고 캐시를 비워 빈 응답 본문을 반환하도록 캐시를 독점할 수 있습니다. 또한 메서드 PURGE를 지원할 수도 있습니다.

Rack Middleware (Ruby on Rails)

루비 온 레일 애플리케이션에서는 Rack 미들웨어가 자주 사용됩니다. Rack 코드의 목적은 x-forwarded-scheme 헤더의 값을 가져와 요청의 스키마로 설정하는 것입니다. 헤더 x-forwarded-scheme: http가 전송되면 동일한 위치로 301 리디렉션이 발생하여 해당 리소스에 대한 서비스 거부 (DoS)가 발생할 수 있습니다. 또한 애플리케이션은 X-forwarded-host 헤더를 인식하고 사용자를 지정된 호스트로 리디렉션할 수 있습니다. 이 동작은 공격자의 서버에서 JavaScript 파일을로드하게 할 수 있어 보안 위험을 초래할 수 있습니다.

403 및 스토리지 버킷

Cloudflare는 이전에 403 응답을 캐시했습니다. 잘못된 인증 헤더로 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

캐시 속임수

캐시 속임수의 목표는 클라이언트가 캐시에 저장될 리소스를 로드하도록 만들어 해당 리소스에 민감한 정보가 포함된 상태로 로드하도록 하는 것입니다.

먼저 .css, .js, .png 등과 같은 확장자는 일반적으로 캐시에 저장되도록 구성됩니다. 따라서 www.example.com/profile.php/nonexistent.js에 액세스하면 캐시가 응답을 저장할 가능성이 높습니다. 왜냐하면 .js 확장자를 볼 때 응답을 저장하기 때문입니다. 그러나 응용 프로그램이 _www.example.com/profile.php_에 저장된 민감한 사용자 콘텐츠를 재생하는 경우, 다른 사용자의 콘텐츠를 도용할 수 있습니다.

테스트할 다른 사항:

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와 같은 잘 알려지지 않은 확장자 사용

이 write-up에서 매우 명확한 예제를 찾을 수 있습니다: https://hackerone.com/reports/593712.
이 예에서는 _http://www.example.com/home.php/non-existent.css_와 같이 존재하지 않는 페이지를 로드하면 _http://www.example.com/home.php_의 내용 (사용자의 민감한 정보와 함께)이 반환되고 캐시 서버가 결과를 저장합니다.
그런 다음 공격자는 자신의 브라우저에서 _http://www.example.com/home.php/non-existent.css_에 액세스하여 이전에 액세스한 사용자의 기밀 정보를 관찰할 수 있습니다.

캐시 프록시는 파일을 콘텐츠 유형이 아닌 파일의 확장자에 따라 캐시해야 합니다. 예를 들어 _http://www.example.com/home.php/non-existent.css_의 경우 text/html 콘텐츠 유형이 아닌 text/css MIME 유형(확장자에 대한 예상)을 가질 것입니다.

여기에서 HTTP 요청 스머글링을 남용하여 캐시 속임수 공격을 수행하는 방법에 대해 알아보세요.

자동 도구

toxicache: 웹 캐시 오염 취약점을 찾고 여러 삽입 기술을 테스트하는 목록의 URL에서 고랭 스캐너.

참고 자료

Trickest를 사용하여 세계에서 가장 고급 커뮤니티 도구를 활용한 워크플로우를 쉽게 구축하고 자동화하세요.
오늘 바로 액세스하세요:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

제로부터 영웅이 될 때까지 AWS 해킹을 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법:

회사를 HackTricks에서 광고하거나 PDF로 다운로드하려면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 얻으세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나트위터** 🐦 @carlospolopm를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

README.md

캐시 독려 및 캐시 속임수

차이점

캐시 독려

발견: HTTP 헤더 확인

발견: 캐시 오류 코드 확인

발견: 키가 없는 입력 식별 및 평가

백엔드 서버로부터 유해한 응답 유도

응답 캐시 가져오기

악용 예시

가장 쉬운 예시

DoS를 위한 캐시 독려

쿠키 처리 취약점을 악용하기 위한 웹 캐시 독려

경로 순회를 통한 API 키 도용을 위한 캐시 오염

여러 헤더를 사용하여 웹 캐시 오염 취약점 악용

제한된 Vary 헤더를 이용한 공격

Fat Get

파라미터 은폐

HTTP 요청 스머글링을 남용하여 HTTP 캐시 독점 공격

웹 캐시 독점을 위한 자동 테스트

취약한 예시

Apache Traffic Server (CVE-2021-27577)

GitHub CP-DoS

GitLab + GCP CP-DoS

Rack Middleware (Ruby on Rails)

403 및 스토리지 버킷

키가 지정된 파라미터 삽입

사용자 에이전트 규칙

부적절한 헤더 필드

새로운 헤더 찾기

캐시 속임수

자동 도구

참고 자료

제한된 `Vary` 헤더를 이용한 공격