[웹 방어 레시피] 2장, 취약점 확인 및 개선

 

웹 애플리케이션이 공격자들에게 아무런 인지 가치를 제공하지 않기에 잠재적 공격 대상이 아닐 것이라 생각할 수 있지만, 이는 잘못된 생각이다. 신원 도용 및 사기를 위한 조직들은 여러분 고객들의 신용카드 데이터를 노리고 있으며, 이런 정보는 전자 상거래 사이트에 때때로 부적절한 방식으로 저장돼 있게 마련이다. 악성코드 제작 그룹들은 대규모 고객층을 감염 대상으로 삼고, 이 과정에서 우리의 웹사이트를 배포지로 활용하려 할 것이다. 또한 핵티비스트들은 서비스 거부 공격으로 웹사이트를 마비시키려 할 것이다. 

 

이와 같은 배경으로 알게 된 가장 신중한 대응 방법은 공격자가 공격하기 전에 모든 취약점을 발견하고 개선하는 것이다. 보안 테스터 및 방어자는 정상적으로 동작하고 있는 웹 애플리케이션과 상호작용하는 동적 분석 도구를 사용하는 경향이 있다. 정확성과 적용 범위의 측면에서 볼 때 가장 이상적인 개선 전략은 웹 애플리케이션 소스 코드 자체의 취약점을 확인하고 수정하는 것이다.

 

내부적으로 개발된 애플리케이션

내부적으로 개발된 웹 애플리케이션의 취약점 개선을 위해 당면한 가장 큰 과제는 단순하게도 부족한 자원이다.

 

다른 유형의 문제점들은 아웃소싱된 웹 애플리케이션 개발 사례를 중심으로 나타난다. 조직은 아웃소싱 개발 작업을 수행할 때 개발 계약의 범위를 정해야 한다.

 

많은 조직들은 취약점을 확인하는 데 드는 비용이 실제 문제를 해결하는 데 드는 비용보다 매우 적다는 사실을 깨닫는다.

 

외부에서 개발된 애플리케이션

취약점이 외부에서 개발된 웹 애플리케이션에 있다고 확인된다면(상용 또는 오픈소스), 사용자가 소스 코드를 수정하는 것은 거의 불가능하다. 이와 같은 상황에서 사용자는 공식 패치가 릴리스될 때까지 기다려야 하므로 근본적으로 벤더의 대응을 기다리는 것 외에는 속수무책이다. 벤더는 대개 공식적으로 지원되는 패치가 나오기 전까지 오래 걸리는 융통성 없는 릴리스 일정을 가지고 있다.

 

다른 일반적인 시나리오는 조직이 상용 애플리케이션을 사용하고 있는 상황에서 벤더가 해당 사업을 중단하거나, 이미 지원이 만료된 버전을 사용하는 경우다. 이와 같은 경우에는 기존 애플리케이션의 코드가 패치될 수 없다.

 

가상 패칭

가상 패칭(virtual patching)이라는 용어는 IPS 벤더로부터 몇 년 전에 만들어졌다. 이것은 웹 애플리케이션에 한정된 용어는 아니며 다른 프로토콜에도 적용될 수 있다. 하지만 가상 패칭은 최근 웹 애플리케이션 방화벽에 일반적으로 사용되고 있다.

 

가상 패칭이란 알려진 취약점을 악용하는 것을 방지하기 위한 보안 정책 집행 계층이다.

 

가상 패칭은 악의적인 트래픽이 웹 애플리케이션에 전송되지 않도록 보안 집행 계층이 트랜잭션을 분석해 전송 중인 공격을 가로채는 방식으로 동작한다. 그 결과 애플리케이션의 소스 코드는 수정되지 않았지만 악성적인 시도는 실패하게 된다. 가상 패칭의 목표는 취약점의 노출된 공격 표면을 줄이는 것이다. 가상 패칭을 이용하는 주된 이점은 위험 감소의 속도다.

 

소스 코드 수정과 가상 패치 프로세스가 상호 배타적이지 않다는 것을 기억하라 이 두 프로세스는 동시에 사용할 수 있으며 또한 동시에 사용돼야 한다. 가상패치는 좀 더 완벽하게 개선된 소스 코드가 프로덕션 단계에 적용될 때까지 빠른 위험 감소를 제공한다.

 

[ 레시피 2-1, 수동 취약점 확인 ]

이 레시피는 ModSecurity를 사용해 실시간 애플리케이션의 트래픽을 모니터링함으로써 결함 및 잘못된 설정을 찾아내거나 취약한 자원에 대한 공격을 확인할 수 있는 방법을 설명한다.

 

수종적인 취약점 식별

웹 애플리케이션 방화벽의 가장 인정받지 못하는 기능 중 하나는 트래픽을 모니터링하거나 분석하는 부분이다. 웹 애플리케이션 방화벽은 인바운드 요청 및 아웃바운드 응답 페이로드에 대한 접근 권한을 가지고 있으므로 HttpOnly 또는 Secure 쿠키 플래그가 누락돼 있는 것과 같은 취약점 및 구성 문제에 대한 귀중한 통찰력을 얻을 수 있다. 웹 애플리케이션 방화벽을 이용하는 주된 이점은 동적 애플리케이션 보안 테스트을 보완해 실제 클라이언트와 웹 애플리케이션이 상호작용하는 것을 모니터링함으로써 실시간으로 발샹하는 내역을 확인할 수 있는 점이다. 따라서 수동적인 취약점 식별이라고 불린다.

 

PVI는 '인바운드 공격을 차단하는' 표준적인 웹 애플리케이션 방화벽과는 상당히 다른 운영 모델이다.

첫째, 애플리테이션의 결함이나 취약한 자원을 식별하기 위해 인바운드 또는 아웃바운드 데이터 모두의 연관성을 분석해야 한다.

둘째, 여러분은 실제 트랜잭션에 지장을 주는 어떤 행위도 하고 싶지 않을 것이다. 이와 같은 트랜잭션은 악의적인 클라이언트가 당신의 사이트를 공격하는 것과 같이 능동적 공격에 초점을 맞춘 규칙이 아님을 기억하라.

 

PVI 옵셥 1: OSVDB 통합

애플리케이션의 결함을 식별하는데 여러 가지 잡근 방법과 자원이 사용될 수 있다. 우리는 OSVDB 프로젝트의 자료를 사용하는 데 초점을 맞출 것이다. OSVDB는 보안 커뮤니티에 의한, 보안 커뮤니티를 위한 독립적인 오픈소스 데이터베이스다. 이 프로젝트의 목표는 보안 취약점에 대해 정확하고, 상세하고, 신속하고, 편향되지 않은 기술적인 정보를 제공하는 것이다.

 

취약점 항목 중 '수동 노트' 부분은 공격 벡터 위치를 식별할 수 있는 개념 증명 공격 코드를 제공하고 있기 때문에 강조돼 표시돼고 있다. 우리는 이 데이터를 PVI 분석 규칙 세트에 활용할 수 있다.

 

PVI 옵션 2: 애플리케이션 결함을 위한 모니터링

■ 파일 인코딩 검사

• 파일 인코딩이 설정되지 않은 경우
• 파일 인코딩이 명시적으로 UTF-8로 설정돼 있지 않은 경우
• 일치하지 않는 파일 인코딩

■ 헤더 검사

• Cache-Control이 no-store로 설정됐는지 검사
• Content-Type 응답 헤더가 설정됐는지 검사
• X-XSS-Protection 응답 헤더가 설정됐는지 검사
• X-FRAME-OPTIONS 응답 헤더가 설정됐는지 검사
• X-CONTENT-TYPE-OPTIONS가 no-sniff로 설정됐는지 검사

■ 쿠키 검사

• 쿠티의 도메인 범위가 느슨한지 검사
• HTTPS를 이용할 경우 secure 플래그가 설정됐는지 검사
• 세션 ID에 대해 HttpOnly 플래그가 설정됐는지 검사

HttpOnly 쿠키 플래그 누락

HttpOnly 크키 플래그에 익숙하지 않거나 당신의 웹 애플리케이션에서 왜 사용해야 하는지 알려면 다음의 자원을 참조하라.

 

• HttpOnly 쿠키를 사용해 크로스 사이트 스크립팅 완화
• OWASP HttpOnly 개요

간단히 설명하자면 애플리케이션이 HttpOnly 플래그를 Set-Cookie 응답 헤더를 통해 설정한다면, 브라우저에게 해당 데이터를 자바스크립트와 같이 클라이언트 측 코드에서 접근하는 것을 보호하도록 지시한다.

 

이 쿠키 옵션 플래그는 크로스 사이트 스크립팅 공격을 방지하기 위해 어떤 작업도 하지 않지만, XSS의 가장 일반적인 최종 목표인 세션ID의 탈취를 방지하는 데 유용하다고 이해해야 한다. HttpOnly가 특효약은 아니지만 구현 후에 얻을 수 있는 이익은 꽤 크다. 이 같은 보호가 동작하기 위해서는 두 가지 주요한 요소가 함께 동작해야 한다. 

 

• 웹 애플리케이션은 세션 ID를 위한 Set-Cookie 응답 헤더에 HttpOnly 플래그를 추가해야 한다.
• 웹 브라우저는 쿠키 플래그를 식별하고 자바스크립트가 내용에 접근할 수 없도록 보안 제약을 적용해야 한다.

[ 레시피 2-2, 능동적인 취약점 식별 ]

이 레시피는 동적으로 웹 애플리케이션을 스캔하고 다양한 취약점을 식별하기 위한 Arachni 웹 애플리케이션 보안 프레임워크의 사용법을 설명한다.

 

당신의 요구에 맞는 적당한 툴을 선택하기 위해서는 웹 애플리케이션 보안 컨소시엄의 웹 애플리케이션 보안 스캐너 평가 기준 문서를 참조하는 것을 권장한다.

 

Arachni는 모의 해킹 수행자와 관리자가 웹 애플리케이션의 보안을 평가할 수 있도록 도와주는 오픈소스, 다기능, 고성능이 특기인 루비 기반 프레임워크다.

 

Arachni는 영리하므로 검사 과정에서 수신하는 HTTP의 응답을 통해 스스로 학습한다. 또한 몇 가지 요소를 이용해 결과의 신뢰성을 평가하고 지능적으로 오탐을 식별할 수 있는 메타 분석을 수행할 수 있다.

 

자세한 Arachni 보고서를 가지고 있으면, 식별 단계에서 식별된 취약점을 완화하려고 시도하는 개선 단계로 넘어갈 수 있다.

 

[ 레시피 2-3, 수동 스캔 결과 반환 ]

이 레시피는 Arachni 스캔 결과로 식별된 취약점을 완화하기 위해 수동으로 ModSecurity 가상 패치를 만드는 방법을 보여준다.

 

Arachni 스캔을 수행해 취야점을 알고 있다면 확인된 이슈를 완화하는 방법을 알아내야 한다. 우리는 이러한 문제들을 가상으로 패치할 수 있는 특정한 ModSecurity 규칙을 작성할 수 있다. 그러나 규칙을 작성하기 전에 블랙리스트(부정)나 화이트리스트(긍정) 중에서 어떤 보안 모델을 사용할지 선택해야 한다.

 

블랙리스트(부정) 보안 모델

블랙리스트 보안 모델은 공격 트래픽을 기술하기 위해 규칙 및 시그니처를 사용한다. 이는 기본적으로 오용 탐지 시스템이다. OWASP ModSecurity CRS는 이 보안 모델을 광범위하게 사용한다. 아이디어는 간단하다. 입력 값에서 특정한 문자 또는 문자의 순서를 찾는다. 만약 찾았다면 차단한다. 메타 문자를 전달하므로 공격자는 데이터베이스 쿼리에 오류가 발생하도록 할 수 있다.

 

블랙리스트 가상 패치

가상 패치를 위해서는 세 가지 주요 구성 요소가 필요하다.

 

• 중요한 URL
• 매개변수 인젝션 위치
• 공격에 사용된 메타 문자

이와 같은 데이터를 통해 이 특정 취약점에 대해 ModSecurity 가상 패치를 만들 수 있다.

 

블랙리스트 회피 문제

이 가상 패치가 스탬 보고서에 의해 식별된 특정 문제를 해결하지만, 여전히 회피 문제로 골치가 아프다. 스캔 보고서는 다음과 같이 세 가지 글자 및 글자의 순서가 SQL 오류 메시지를 야기한다고 알려준다.

 

• '
• '
• --

문제는 이 리스트가 SQL 쿼리와 문제를 발생시킬 수 있는 모든 메타 문자를 나열하지 못하는 것이다. 입력 값 검증을 위해 가상 패치를 작성하는 경우 가능한 한 오직 예상된 글자만 허용하고 나머지는 모두 차단하는 화이트리스트 접근 방법을 사용하는 것을 권장한다.

 

화이트리스트(긍정) 보안 모델

입력 유효성 검사에서 화이트리스트 보안 모델 접근 방식은 회피 가능성이 낮으므로 블랙리스트 접근 방식보다 더욱 강렬하다. 우리는 수동적으로 긍정적인 보안 가살 패치를 생성한느 것을 논의하지만, 여기서 언급되는 내용은 레시피 1-1을 구현하면 자동으로 달성될 수 있다는 것에 유의하라.

 

회피 가능성을 제한하기 위해 긍정적인 보안 모델 가상 패치는 몇 개의 요청 특성이 있어야 한다.

 

• 동일한 이름을 가진 매개변수의 수를 제한한다. 이는 HTTP 매개변수 오염 공격을 방지하는 데 도움이 된다.
• 매개변수의 위치를 QUERY_STRING이나 POST_LAYLOAD로 제한한다. 보안 제한은 때때로 모든 매개변수 위치에 잘못 적용된다.
• 허용되는 캐릭터 세트를 제한한다. 인터프리터 문제를 야기할수 있는 메타 문자를 방지하기 위해 허용되는 글자만 화이트리스트 처리한다.
• 매개변수 유형의 양식을 제한한다. 가능하다면 예상되는 약식을 적용한다.
• 매개변수 길이를 제한한다. 이는 대형 공격 페이로드를 방지하는 데 도움이 된다.

이와 같은 개념을 이해하면, 스캐너에 의해 식별된 SQL 인젝션 취약점에 대한 업데이트된 화이트리스트 방식의 가상 패치를 검토할 수 있다.

 

[ 레시피 2-4, 자동 스캔 결과 반환 ]

이 레시피는 식별된 취약점을 완화하기 위해 펄 스크립트를 사용해 Arachni XML 스캔 보고서 데이터를 ModSecurity 가상 패치를 자동 변환하는 방법을 보여준다.

 

레시피 2-3에서 살펴본 것처럼 Arachni 스캔 결과 보고서 데이터를 검토해 수동으로 가상 패치를 생성하는 것은 분명히 가능하다. 이와 같은 접근 방식의 주요 단점은 여러분이 보호해야 할 다수의 웹 애플리케이션을 보유하고 있을 경우 프로세스를 확장하기 어렵다는 점이다.

 

이상적으로 말하면 스캔 보고서 데이터에 대한 가상 패치 생성을 자동화할 수 있어야 한다.

 

가상 패치들은 공동 탐지 유형을 활용한다. OWASP ModSecurity CRS가 공격 페이로드를 탐지할 수 있도록 하고 Arachni 스캔에서 식별된 위치와 인젝션 벡터 위치 상세 정보를 연관한다.

 

변환 스크립트를 사용해 Arachni 스캔 보고서 데이터를 ModSecurity 가상 패치 규칙으로 자동 변환하는 것은 수동 생성하는 것보다 확실히 확장성이 좋다. 주기를 설정하거나 애플리케이션이 업데이트 됐을 때와 같이 정기적으로 반복 수행될 필요가 있는 경우 더욱 그렇다.

 

[ 레시피 2-5, 실시간 자원 평가 및 가상 패치 ]

이 레시피는 실시간, 온디밴드 방식의 자원 평가 및 가상 패치를 위해 ModSecurity와 Arachni를 통합하는 방법을 보여준다.

 

동작 원리

1. ModSecurity는 실제 클라이언트가 자원에 접근할 때 식별한다.

2. ModSecurity는 URL, 매개변수, 쿠키 데이터를 추출하고 루아 스크립트를 사용해 원격 Arachni RPC 호스트에 스캐닝을 위해 이 정보를 전달한다.

3. ModSecurity는 로컬 ModSecurity 자원 영구 저장소에 메타 데이터를 저장한다.

4. Arachni는 전달된 벡터에 대해서만 지정된 스캔, 평가를 수행한다. (이는 추가 자원 및 링크를 열거하기 위해 크롤링을 수행하지 않는 것을 의미한다.)

5. Arachni는 보고서를 생성한다.

6. ModSecurity는 클라이언트가 자원에 접근할 때마다 RPC 디스패처를 이용해 검사한다.

7. ModSecurity는 완료된 보고서를 가져와서 피싱한 후 다양한 취약점 유형을 확인한다.

8. ModSecurity는 각 공격 유형에 따라 어떠한 매개변수가 취약한지 식별하는 RESOURCE 변수를 설정한다.

9. ModSecurity는 알려진 취약점 데이터와 OWASP ModSecurity CRS에서 캡처한 어떤 활성화된 공격과 연관한 후 차단 행위를 지시한다.

 

통합의 이점

통합을 이용하면 두 가지 주요 장점이 있다.

 

• 개선하기 위한 시간 수치를 단축: Arachni 보고서 데이터를 가상 패치로 변환하기 위해 중간에서 처리해야 하는 절차를 제거함으로써 개선하기 위한 시간 수치를 획기적으로 단촉시킨다.
• 애플리케이션 스캐닝 범위: DAST 툴은 동적 컨텐츠 생성 및 인증에 대한 제한 등의 문제로 애플리케이션 내에 자원을 열거하는 데 종종 어려움을 겪는다. 이와 같은 통합으로 실제 사용자가 실제 웹 브라우저를 통해 웹 애플리케이션과 상호작용하는 것을 허용하기 때문에 이 두 가지 문제를 해결하는 데 도움이 될 수 있다. 우리는 간당히 관련 내용을 추출해 동일한 URL에 동일한 접근을 할 수 있고 동일한 인증 정보를 사용하는 Arachni에 전달할 수 있다.

Arachni RPC 디스패처

대부분의 DAST 툴은 보안 분석가들이 툴을 그들의 컴퓨터에서 실행할 수 있도록 라이언트 데스크톱 아키텍처를 가지고 있다. 스캔은 HTTP 클라이언트처럼 동작하며 대상 웹 애플리케이션과 상호작용하고 보고서를 생성한다. 다행히도 Arachni는 RPC 서비스와 함께 제공된다. 이 서비스의 목적은 커맨드 라인 기반의 스캔을 사용할 수 있도록 하는 것이다.

 

 

---

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