[웹 방어 레시피] 3장, 독을 품은 폰(해커 트랩)

우리는 애플리케이션 내부에 대해 아는 바 없이 공격자로부터 웹 애플리케이션을 보호해야 한다. 이와 같은 정보가 없다면 정상적인 트래픽의 홍수에 숨어있는 악의적인 행위를 식별하기는 어려울 것이다. 정상적인 사용자가 웹 애플리케이션을 어떻게 사용하는지 이해하면, 공격자가 이와 같은 사용 프로파일에서 벗어날 때 알아낼 수 있다. 불행히도 대부분의 조직인 악의적인 행위를 식별하기 위해 시그니처 기반의 탐지 시스템을 사용하려고 한다.

 

만약 모든 정상적인 사용자의 트래픽을 제거하도록 설정할 수 있다면 비정상적인 트래픽만 남게 될 것이다. 이는 우리가 허니트랩이라고 부를 허니팟의 개념을 제공해준다.

 

허니트랩의 개념

허니팟 시스템이 실제 대상처럼 행동하도록 네트워크에 배포하는 별도의 호스트를 말한다면, 허니트랩은 웹 애플리케이션 전반에 걸쳐 심어져서 공격자에게 가상의 지뢰밭처럼 동작한다. 프로덕션을 위한 목적이 있는 것은 아니며 어떠한 상호작용이나 변경도 허가되지 않았으므로 상호작용을 한다면 확실히 의심할 수 있다.

 

허니트랩의 진정한 가치는 정상적인 사용자로부터 악성적인 사용자를 빠르게 구별할 수 있다는 점에서 나온다. 허니트랩은 공격의 다양한 단계에서 지뢰선(인계철선)처럼 동작한다.

 

허니트랩을 사용하는 데 따른 세 가지 주요 이점

• 높은 정확도의 경고 : 허니트랩의 행위는 정의에 따라 인가되지 않은 행위다. 이는 오탐 경고를 줄이는 데 상당히 효과적이다.
• 적은 수의 경고 : 허니트랩은 클라이언트가 상호작용하거나 조작할 경우에만 경고를 발생한다. 이는 보안 분석가가 검증해야 할 경고의 양을 줄여준다.
• 미탐을 식별 : 페이로드를 사전에 알고 있으므로 데이터 조작 공격을 식별하는 데 탁월하다.

허니트랩을 단순히 웹 애플리케이션에 위치시킨 후 무엇이라도 변경됐다면 가능성이 가장 높은 공격자를 발견할 수 있다.

 

레시피 3-1, 허니팟 포트 추가

이 레시피는 요청을 전송한 어떠한 클라이언트라도 경고하기 위해 웹 서버 설저에 추가적인 리스닝 포트를 넣는 방법을 보여준다.

 

완전히 새로운 허니팟 시스템을 구축할 필요 없이 현재의 웹 서버 플랫폼을 쉽게 재사용할 수 있다. HTTP 요청 트래픽을 받아들이는 네트워크 포트를 추가함으로써 허니트랩을 구현할 것이다. 이 포트들은 정상적인 목적을 가지고 있지 않으므로 수신한 어떠한 트래픽이라도 의심한다.

 

아파치 Listen 지시자

아파치의 Listen 지시자는 요청을 받아들이고자 하는 포트 또는 IP 주소와 포트의 조합을 정의한다. 기본적으로 HTTP 80 포트를 받아들이는 하나의 Listen 지시자가 httpd.conf 파일에 활성화됐다.

 

setvar:ip.malicious_client=1

sever 액션에 주의해야 한다. 클라이언트가 이 포트로 트래픽을 보낸다면 IP 영구 저장소 컬렉션 내에 변수를 설정해 해당 클라이언트가 악의적이라고 표시한다. 이와 같은 접근 방식의 장점은 자동화된 악성 클라이언트를 쉽게 식별할 수 있으며 정상적인 프로덕션 웹 애플리케이션에 있는 ModSecurity 규칙에 이 정보를 사용할 수 있다는 것이다. 

 

이처럼 허니트랩 포트 기술은 클라이언트가 요청을 보내자마자 악성일 가능성을 알 수 있기 때문에 실제 애플리케이션의 조기 경보 시스템 역할을 한다. 이 정보를 바탕으로 즉시 클라이언트를 차단시킬 수 있으며, 감시 목록에 등록하고 이상징후 점수를 증가시킬 수도 있다.

 

레시피 3-2, ROBOTS.TXT에 가짜 DISALLOW 항목 추가

이 레시피는 robots.txt 파일에 Disallow 항목을 추가해 클라이언트가 해당 위치에 접근을 시도하면 경고를 발생시키는 방법을 보여준다.

 

Robots 예외 표준

Robots 예외 표준은 웹사이트 소유자가 검색 엔진 크롤러에게 어떤 자원에 대해 인덱스를 허용하는지 알려주기 위해 만들어졌다. Robots.txt라는 파일은 웹사이트의 도큐먼트 루트에 배치된다. 이 파일 내에서 사이트 관리자는 allow, disallow 명령어를 포함해 웹 크롤러에게 어떤 자원에 접근해야 하는지 알려준다. 

 

Robots.txt는 정상적인 목적을 위해 제공되지만, Robots 예외 표준은 단지 제안 사항이며 접근 제어 기능을 제공하지 않는다. 문제는 외부 클라이언트에게 웹사이트의 민감한 구역을 알려주면서 그들이 파고들지 않도록 바라는 것이다. 그들은 이 장소에 접근하려고 분명히 시도할 것이다. 바로 그 안에 또 다른 허니트랩 탐지 포인트를 배치할 기회가 있다.

 

Robots.txt 파일을 동적으로 업데이트 

ModSecurity를 통해 robots.txt 항목에 허니트랩을 동적으로 삽입할 수 있다. 우선 다음과 같은 지시자를 활성화해야 한다. 

SecContentInjection On

이 지시자는 ModSecurity에게 실시간 스트림에 데이터를 추가하길 원한다고 알려준다.

 

가짜 인증 구현

가자 디렉터리 개념 확장이 가짜 인증을 위한 계층을 추가하는 것이다. 이는 두 가지 영역에서 유용하다.

 

• 요청에 대해 401 인증 필요 HTTP 응답 코드와 함께 응담하면 허니트랩 자원을 더욱 진짜처럼 보이게 한다.
• 인증 정보가 필요하다는 응답을 받게 되면 공격자는 수동적으로 사용자명과 비밀번호 조합을 입력하거나 자동화된 공격을 시도한다. 이와 같은 경우 올바른 인증 조합이 존재하지 않기 때문에 우리가 이길 수밖에 없는 싸움이가. 공격자는 무작위 대입 방식으로 인증을 시도하면서 시간을 낭비하고 있는 것이다.

기존 ModSecurity SecRule에서 단계를 변경하고 deny 액션을 추가하고 ModSecurity가 401 응답 코드를 응답하도록 함으로써 가짜 인증 부분을 포함하게 변경할 수 있다.

 

레시피 3-3, 가짜 HTML 주석 추가

이 레시피는 가짜 HTML 주석 데이터를 추가한 후 클라이언트에 의해 사용될 경우 플래그하는 방법을 보여준다.

 

HTML 주석

HTML은 개발자가 HTML 주석 정보를 포함할 수 있도록 문법을 제공한다. HTML RFC에서는 다음과 같이 설명하고 있다.

<!-- 이 부분은 주석이다 --> <!-- 이 부분은  여러 줄에 걸친 주석이다. -->

마크업(markup) 선언 시작 구분자("<!")와 주석 시작 구분자("--") 사이의 공백은 허용되지 않으나 주석 종료 구분자 "--"와 마크업 선언 종료 구분자(">") 사이의 공백은 허용된다. 주로 발생하는 오류는 주석 내용에 하이픈 문자열("---")을 포함하는 경우다. 주석 내에 연속해서 두 개 또는 그 이상의 하이픈을 넣어서는 안 된다. 주석 안에 있는 정보는 특별한 의미를 가지지 않는다.

이 기능은 본래 목적 자체는 분명 도움이 되지만 종종 민감한 데이터를 누설한다. 이 정보는 애플리케이션의 내부 동작을 노출시키므로 클라이언트에 전송돼서는 안 된다. 이 데이터를 통해 공격자는 여러분의 애플리케이션에 대해 더 정교한 계획을 세울 수 있으며 공격을 실행할 수 있다.

 

가짜 HTML 주석 추가

SecStreamOutBodyInspection On

이 지시자는 RESPONSE_BODY 변수 데이터를 재할당 가능한 버퍼에 배치해 내용을 수정하고 응답 바디 스트림에 재삽입 가능하도록 한다. 쉽게 말하자면 이 지시자는 아웃바운드 응답 바디 데이터를 수정할 수 있게 한다.

 

HTML 소스 코드 내에서 강조 표시된 FORM 태그를 주목해야 한다. 이는 인젝션 포인트로 사용할 중요한 데이터 요소다.

 

레시피 3-4, 가짜 숨겨진 폼 필드를 추가

이 레시피는 기존 폼에 가짜 숨겨진 폼 필드를 추가하고 데이터가 조작된 경우 경고하는 방법을 보여준다.

 

숨겨진 폼 필드

HTML의 숨겨진 폼 필드는 브라우저가 사용자에게 해당 필드를 보여주지 않는다는 하나의 뚜렷한 차이를 제외하고는 일반 폼 필드와 동일하다. 숨겨진 필드는 하나의 요청에서 다른 요청으로 데이터를 전달하는 매커니즘으로 사용되며 내용이 변경돼서는 안 된다. 브라우저는 해당 폼 필드를 감추지만 사용자는 여전히 데이터에 접근할 수 있다. 그들은 소스보기를 하거나 브라우저의 플러그인을 사용할 수 있다.

 

Groundspeed 플러그인의 주된 장점은 페이지의 HTML 요소와 실제 사용자 인터페이스를 연관시켜주는 것이다.

 

&context=front

굵게 표시된 context 매개변수 데이터가 요청 바디의 마지막에 있는 것을 확인할 수 있다. 이는 숨겨진 폼 필드 데이터다. 이 데이터를 보면 해당 매개변수 데이터가 숨겨진 폼 필드에서 전송됐다는 것을 확인할 방법이 없다. 공격자는 웹 브라우저의 범위에서 벗어나면 다른 입력 필드와 마찬가지로 쉽게 데이터를 조작할 수 있다.

 

가짜 숨겨진 폼 필드 추가 

가짜 HTML 주석을 추가했던 것처럼 가짜 HTML 숨겨진 폼 필드를 주입하기 위해 동일한 방법을 사용할 수 있다. 이 기술의 핵심은 </form> HTML 태그다. 우리는 허니트랩 데이터를 </form> 바로 앞에 삽입할 것이다.

 

이 규칙이 적용되면 모든 HTML 폼에 숨겨진 허니트랩 매개변수 데이터가 주입된다.

 

레시피 3-5, 가짜 쿠키 데이터를 추가

이 레시피는 가짜 쿠키 데이터를 추가하고 데이터가 조작된 경우 경고를 발생시키는 방법을 보여준다.

 

쿠키 사용

HTTP 프로토콜은 기본적으로 세션을 인식하지 않는다. 이는 각 트랜잭션이 다른 트랜잭션과 독립적임을 의미한다. 따라서 애플리케이션은 사용자가 누구며 기존에 어떤 행위를 했는지 추적하는 방법이 필요하다. 쿠키는 정확히 이러한 목적을 위해 만들어졌다. 애플리케이션은 Set-Cookie 응답 헤더 데이커를 클라이언트 웹 브라우저에게 발행한다. 이 쿠키 데이터는 브라우저에게 다음 요청 시 웹 애플리케이션에 다시 전송되도록 지시한다.

 

Set-Cookie 응답 데이터가 있다. 두 개의 헤더는 로컬 쿠키 값이 존재한다면 삭제하는 역할을 한다. 후속 요청을 보낸다면 이 헤더들은 요청 헤더에 포함된다.

 

쿠키 변조 공격

공격자는 매개변수 페이로드를 노리는 것처럼 애플리케이션이 배포하는 크키 데이터를 변조하려고 시도한다. 애플리케이션은 각 요청마다 매개변수와 쿠키 데이터를 평가한다. 쿠키 데이터는 종종 권한 제한을 제어하므로 공격자에게 더운 매력적인 대상이 될 수 있다. 만약 공격자가 쿠키 데이터를 변조할 수 있으면, 완전히 새로운 사용자가 되거나 새로운 사용자 인터페이스 옵션이 표시되거나 응용프로그램 내에서 더 많은 권한을 얻을 수 있다.

 

가짜 쿠키 데이터 추가

 

[ 구현을 위한 두 가지 고려 사항 ]

• 언제 가짜 Set-Cookie 데이터를 발생시킬 것인가? 우리의 쿠키 허니트랩 데이터가 무해한 것처럼 보이길 원하므로, 애플리케이션 자체적으로 정상적인 Set-Cookie 응답 헤더를 발행할 때만 추가하고자 한다.
• 가짜 Set-Cookie 데이터의 이름을 무엇으로 할 것인가? 우리의 허니트랩 데이터가 잘 섞이기를 원하므로 현재의 쿠키 이름과 유사한 이름으로 시도해야 한다.

 

---

출처: ModSecurity를 활용한 웹 애플리케이션 방어 레시피, 라이언 바넷 지음