소프트웨어 전문 컨설팅 및 기술지원 전문

By Waratek / June 17, 2019 / Alerts, Legacy, Patching, Technical, Zero Day 
본문 : https://www.waratek.com/new-weblogic-zero-day-rce-vulnerability/

[Update June 18, 2019]

오라클은 이 새로운 취약점 CVE-2019-2729에 대한 패치를 발표했습니다.

이 Oracle 수정 사항은 이전 수정 사항과 동일한 제한 사항이 있습니다.

• Oracle 패치는 WebLogic 버전 10.3.6 또는 12.1.3 만 수정합니다. CVE-2019-2725에 대한 보안 경고 패치를 적용하려면 이전 버전의 사용자가 업그레이드해야합니다.
• 모든 서버는 최신 PSU가 최신 상태 여야합니다.

Waratek의 직렬화 해제 보호는 모든 버전의 WebLogic (Oracle에서 지원하지 않는 버전 포함)에 적용 할 수 있으며 CPU 또는 PSU를 먼저 설치할 필요가 없습니다.

WebLogic 사용자는 여전히 위험합니다.

KnownSec 404 보안 팀의 업데이트에 따르면 CVE-2019–2725에 대한 Oracle 수정 프로그램이 다시 우회되었습니다. 트위터의 보고서에 따르면 오라클의 수정을 우회하는 익스플로잇은 이미 발견되었습니다.

오라클이 이 취약성을 고치기 위해 고군분투한 이유는 웹로그에서 블랙리스트 완화 전략을 사용하기 때문이다. 공격자는 블랙리스트에 포함 된 가젯 (구성 요소)을 사용하지 않는 대체 페이로드를 작성해야합니다. 이것은 고전적인 두더지 게임입니다. 오라클이 블랙리스트 완화 전략을 계속 사용하는 한 공격자와 보안 연구원은 오라클의 수정을 우회합니다. 끝없는 게임입니다.

Oracle의 블랙리스트 접근 방식으로 인해 WebLogic 사용자는 Oracle의 최신 패치를 사용하더라도 CVE-2019-2725 페이로드 변형 및 직렬화 해제 제로 데이 악용으로부터 보호되지 않습니다. 우리는 @ hkashfi가 여기에 잘 요약했다고 생각합니다.

Waratek은 역 직렬화 취약점을 완전히 해결합니다. 

Waratek의 역 직렬화 솔루션은 가제트의 블랙리스트를 사용하지 않으므로 모든 종류의 페이로드 변형, 대체 익스플로잇, 제로 데이 등에 영향을받지 않으며 entry point와 무관합니다.

따라서 일단 Waratek을 구현하면 역 직렬화 취약점으로부터 보호됩니다. - full stop.

Act now

이 취약성의 심각성은 서버(RCE)를 완전히 손상시킬 수 있어 매우 중요합니다. 원격 코드 실행 취약점은 암호화 마이닝 맬웨어, 랜섬웨어에 의해 악용 될 수 있으며 데이터 유출 및 유출을 달성하는데도 사용됩니다.

관련된 내용의 케이스스터디 내용 확인은 여기를 클릭하세요

[Update May 22, 2019]

지난 달, Oracle WebLogic 서버 (CVE-2019-2725)의 치명적인 취약점에 대해 모든 Waratek 고객에게 보안 권고를 발표했습니다. 오라클은 모든 고객에게 가능한 빨리 제공된 업데이트를 적용하여 영향을받는 버전을 10.3.6.0, 12.1.3.0으로 표시하는 보안 경고를 발행했습니다.

이 업데이트 된 커뮤니케이션은 Waratek 리서치 팀이 Oracle Security Alert에 나열되지 않은 이전 버전의 WebLogic에 여전히 CVE-2019-2725에보고 된 RCE 취약점이 포함되어 있음을 확인했음을 알려드립니다.  

10.3.6.0 및 12.1.3.0 이전의 2 버전 이상에서 취약점의 존재 여부를 테스트하고 확인했습니다. 우리의 교정에 대한 조언은 변함이 없으며 WebLogic 사용자는 시스템을 보호하기 위한 조치를 취해야합니다. Waratek의 원래 치료 지침은 다음과 같습니다. Waratek 고객은 궁금한 점이 있으면 계정 관리자 나 info@waratek.com에 문의하십시오.

[Update April 28, 2019]

2019 년 4 월 24 일 발행 된 Waratek의 지침에 따라 Oracle은 KnownSec 404의 연구원들이 공개적으로 보고한 제로 데이 역직렬화 원격 명령 실행 취약점을 공식적으로 확인했습니다. 이 중요한 취약점 (CVSS 점수가 9.8 인 CVE-2019-2725)은 wls9_async_response.war 및 wls-wsat.war 구성 요소가 활성화 된 모든 WebLogic 버전 (최신 버전 포함)에 영향을줍니다.

오라클은 2019 년 4 월 26 일 금요일에 모든 고객에게이 보안 경보가 제공하는 업데이트를 최대한 빨리 적용 할 것을 강력히 권고했습니다. Oracle Security Alert Program이 제공 한 패치는 Oracle 평생 지원 정책의 프리미어 지원 또는 확장 지원 단계에 포함 된 제품 버전에만 제공됩니다.

Waratek은 모든 WebLogic 사용자가 CVE-2019-2725에 대한 Oracle의 사용 가능한 수정과 관련하여 다음 사항을 숙지 할 것을 권장합니다:

• Oracle 패치는 특정 지원 계층에서만 사용할 수 있습니다. 위의 링크 된 Oracle 정책을 참조하십시오.  
• Oracle 패치는 WebLogic 버전 10.3.6 또는 12.1.3 만 수정합니다. CVE-2019-2725에 대한 보안 경고 패치를 적용하려면 이전 버전의 사용자는 업그레이드해야합니다. 
• 모든 서버는 최신 PSU에 최신 상태 여야합니다.

Immediate Action is Necessary

이 중요한 취약점이 활발하게 악용되고 있다고보고 된 바 있습니다. 모든 WebLogic 사용자는 가능한 한 빨리 조치를 취해야합니다. 공격이 성공하면 WebLogic 서버가 완전히 손상 될 수 있습니다.

Waratek의 고객은 이미 보호 받고 있습니다

• 보호 모드에서 deserial zero-day (CWE-502) 규칙을 활성화 한 기존 Waratek Secure 및 Waratek Enterprise 고객은 이미 보호되어 있습니다. 추가 조치가 필요하지 않습니다.
• 보호 모드에서 ARM 포크 처리 규칙을 활성화 한 기존 Waratek Patch 고객은 이미 보호되어 있습니다.
• Waratek의 ARMR 플랫폼은이 제로 데이 중요 취약점에 대한 완전한 치료를 제공하므로 Waratek 고객은 긴급하게 CVE-2019-2725 용 Oracle 핫픽스를 적용 할 필요가 없습니다.
• 이 Oracle WebLogic 취약점의 영향을 받아 Oracle의 지원 매개 변수 이외의 즉각적인 보호 기능뿐만 아니라 패턴 일치 및 서명을 기반으로하는 비효율적 인 솔루션을 사용하는 고객은 Waratek (info@waratek.com)에 문의하십시오.

[Original Guidance, posted April 24, 2019]

신뢰할 수있는 출처에서 제공하는 잠재적 WebLogic 제로 데이에 대한 알림을 받았습니다. 보고서에 따르면 Oracle WebLogic wls9_async 및 wls-wsat 구성 요소는 역직렬화 원격 명령 실행 취약성을 트리거합니다. 이 취약점은 wls9_async_response.war 및 wls-wsat.war 구성 요소가 사용 가능한 모든 WebLogic 버전 (최신 버전 포함)에 영향을줍니다.

현재이 취약점은 공급 업체에 의해 수정되지 않았습니다.

Waratek 고객 조언

• 보호 모드에서 deserial zero-day (CWE-502) 규칙을 활성화 한 기존 Waratek Secure 및 Waratek Enterprise 고객은 이미이 새로운 제로 데이로부터 보호됩니다. 추가 조치가 필요하지 않습니다.
• 보호 모드에서 ARMF 프로세스 규칙을 활성화 한 기존 Waratek Patch 고객은이 새로운 제로 데이로부터 이미 보호됩니다.

이 새로운 Oracle WebLogic 0-day의 영향을 받고 공급 업체의 패치 가용성에 의존하지 않고 즉각적인 보호에 관심이있는 비 Waratek 고객과 패턴 일치 및 서명을 기반으로하는 비효율적 인 솔루션을 사용하는 고객은 Waratek.com (info @ waratek)에게 문의하십시오. 

와라텍 정보 바로보기 ☞

by Apostolos Giannakidis

Java 역 직렬화 문제는 응용 프로그램이  신뢰할 수없는 소스에서 데이터를 역 직렬화 할 때  발생하며 지난 몇 년 동안 가장 널리 퍼진 보안 취약점 중 하나입니다.

이 글은 Java deserialization 취약점에 대한 배경 지식을 제공하고 기존 완화 기술의 한계를 설명합니다. 여기에 제시된 정보는 Gabriel Lawrence, Chris Frohoff, Steve Breen, Matthias Kaiser, Alvaro Muñoz 및 Christian Schneider의 공개 된 연구를 기반으로합니다. ; Java deserialization 취약점의 주요 연구원.

이 글의 끝 부분에서 현재 사용 가능한 솔루션이 엔터프라이즈 환경에서 문제를 올바르게 해결하기에 적합하지 않은 이유와 런타임 가상화 기반의 혁신적인 솔루션이 이 문제를 이상적으로 해결 하는 방법을 설명하는 정보를 찾을 수 있습니다 .

배경

직렬화 또는 마샬링은 메모리 객체를 파일 시스템에 저장하거나 다른 원격 시스템으로 전송하기 위해 메모리 객체를 바이트 스트림으로 변환하는 프로세스입니다. 비 정렬 화라고도하는 역 직렬화는 직렬화 된 바이트 스트림을 기계 메모리의 오브젝트로 다시 변환하는 역 프로세스입니다. 모든 주요 프로그래밍 언어는 기본 직렬화 및 역 직렬화를 수행하는 기능을 제공하며 대부분 기본적으로 안전하지 않습니다.

Lawrence, Frohoff , Breen 및 Kaiser의 최근 연구에 따르면, 널리 사용되는 원격 명령 실행 을 허용하는  Java 응용 프로그램 및 프레임 워크에 대한 직렬화에 대한 공격을 수행했습니다.  결과를 입증하기 위해 안전하지 않은 Java 객체 역 직렬화를 이용하는 페이로드를 생성하는 "개념 증명"도구 인 "ysoserial"도구를 만들었습니다. 연구의 주된 목적은 Apache Commons Collection 라이브러리에서 위험한 클래스를 찾는 것이 었습니다. 해당 클래스의 이름은 InvokerTransformer입니다. 이 발견은 주로 Apache Commons Collection (ACC) 라이브러리의 인기로 인해 주목을 받았습니다. CERT (Computer Emergency Response Teams)조차도 ACC 라이브러리의 취약성에 대한 취약점을 발표했습니다. Apache Commons Collection에 의존하는 모든 애플리케이션, 서버 또는 프레임 워크는 잠재적으로 취약했습니다. JBoss, WebLogic, WebSphere 및 Jenkins는 영향을받는 시스템 중 일부에 불과했습니다.

역 직렬화 익스플로잇의 모든 내부 세부 사항을 설명하는 것은 이 기사의 범위를 넘어서며 이미 큰 성공을 거두었습니다 . 그러나 기존 완화의 격차를 파악하고 문제에 대한 새로운 솔루션의 필요성을 강조 할 수있는 몇 가지 중요한 개념을 설명하려고 합니다.

InvokerTransformer는 어떻게 침입자가 시스템을 악용하도록 허용하는가?

InvokerTransformer의 목표는 reflection을 사용하여 메소드를 호출하여 컬렉션의 객체를 변환하는 것입니다 . 공격자는이 기능을 악용하고 원하는 방법을 호출 할 수 있습니다. 역 직렬화 PoC 익스플로잇 도구 ysoserial은 InvokerTransformer를 악용하고 컬렉션 객체를 변환하는 대신 대상 시스템에서 임의의 명령을 실행 하는 Runtime.exec () 를 호출합니다.

InvokerTransformer를 악용하고 Runtime.exec ()와 같은 임의의 위험한 메서드를 호출하려면 공격자가 특수하게 조작 된 메서드 시퀀스를 만들어야합니다. 시퀀스의 각 메서드를 "gadget"라고하며 악성 메서드 호출 시퀀스를 "gadget chain "이라고합니다. Apache Commons Collections의 경우 InvokerTransformer는 악성 gadget chain의 gadget입니다. 새로운 gadget chain이 식별 될 때마다 ysoserial 도구가 업데이트되어 이러한 gadget chain의 작동 방식을 보여줍니다.

여기서 주목할 점은 대부분의 gadget chain은 Apache Commons Collection의 InvokerTransformer와 같은 타사 구성 요소의 gadget을 사용한다는 것입니다. 그러나 third-party gadgets 이 포함 되지 않은  가젯 체인이 있습니다 . 이 가젯 체인에는 JRE gadget 만 포함됩니다. 그러한 체인이 시스템을 악용하기 위해서는 취약한 JVM 버전 만 있으면됩니다. 이러한 gadget chain은 기존 완화 솔루션을 쉽게 우회 할 수 있으므로 종종 golden gadget chains  이라고 합니다.

공격 메커니즘은 다음 단계로 요약 할 수 있습니다.

• 취약한 응용 프로그램은  user-supplied 직렬화 된 개체를 허용합니다.
• 공격자는 악의적 인 gadget chain을 만들어이를 일련의 바이트로 직렬화하여 응용 프로그램으로 보냅니다.
• 취약한 응용 프로그램은 수신 된 바이트 스트림을 읽고 개체 구성을 시도합니다. 이 작업을 "역직렬화"라고합니다.
• 역 직렬화 중에 gadget chain이 실행되어 시스템이 손상됩니다.

시스템 손상의 영향은 무엇입니까?

페이로드에 따라 가젯 체인은 원격 코드 삽입, 원격 명령 실행, 서비스 거부 등을 수행 할 수 있습니다. 대부분의 경우 인증없이 익스플로잇이 가능합니다. 마지막으로 WebLogic과 같은 서버에 대한 공격은 실행중인 모든 웹 응용 프로그램에 영향을 줄 수 있습니다. 이러한 이유로 Java  deserialization 취약점 은 환경에 따라 7.5에서 10까지 의 CVSS 점수 를 가진 중요한 취약점으로 간주됩니다 .

위 시나리오를 공격에 취약하게 만드는 것은 무엇입니까?

Java deserialization 취약점"의 특징이 되는 두 가지 필요 기준.

• 소프트웨어는 공격자가 액세스 할 수있는 위치에서 직렬화 된 데이터를 수락하고 비 정렬 화해야합니다.
• 안전하지 않은 클래스 (가젯)는 응용 프로그램의 클래스 경로에 있어야합니다.

이는 애플리케이션이 취약한 버전의 Apache 취약점 모음을 사용하는 것만으로는 충분하지 않음을 의미합니다. 또한 안전하지 않은 위치에서 데이터를 역직렬화 합니다.

이것이 바로 Apache Foundation  이 InvokerTransformer와 특정 기능을 구현하는 다른 클래스가이 취약점에 대한 책임이 있다고 주장 하는 이유 입니다. 취약점을 유발하는 것은이 두 가지 기준의 조합입니다. InvokerTransformer 자체는 취약하지 않습니다 .

아파치는이 취약점의 발견에 어떻게 대응 했습니까?

Apache는 InvokerTransformer가이 취약점에 대해 책임을지지 않는다고 말했지만, 직렬화 할 수있는 기능을 제거하여 InvokerTransformer를 강화했습니다. 그러나 이는 이러한 변경으로 인해 이전 버전과의 호환성이 손상되고 InvokerTransformer 직렬화에 의존 한 모든 응용 프로그램이 중단 될 수 있음을 의미합니다. 이 한계를 극복하기 위해 Apache 커뮤니티는 잠재적으로 안전하지 않은 이전 InvokerTransformer 동작을 복원 할 시스템 특성을 도입하기로 결정했습니다.
따라서 Apache의 수정으로 시스템은 직렬화에 InvokerTransformer를 사용할 수 없으며 동시에 보호 할 수 없습니다.
시스템 특성에 따라 둘 중 하나 여야합니다.

여기서 이해 해야 할 것은 InvokerTransformer를 직렬화하지 않으면 공격자가 더 이상 InvokerTransformer를 사용하여 악의적 인 가제트 체인을 만들 수 없다는 것입니다.

이것이 핵심 문제를 해결 할 까요? 아니요. 그것은 그저 문제를 임시적으로 해결하는 패치일 뿐입니다.

두통이 있다고 머리를 자른다고 문제가 해결되지 않는다는 그리스어 표현이 있습니다. 이것이 바로 InvokerTransformer에서 일어난 일입니다. 직렬화 기능을 비활성화하면 문제를 해결할 수있는 올바른 방법이 아니므로 응용 프로그램이 중단되고 시스템이 자동으로 안전하지 않습니다. 또한 InvokerTransformer 만 알려진 가제트는 아닙니다. 다른 몇 가지가 확인되었으며 앞으로 더 많은 것들이 발견 될 것입니다. 가젯으로 사용할 수있는 클래스를 비활성화하면 끝없는 Whack-a-Mole 게임 만 생성됩니다 .

ysoserial exploit 키트는이 끝없는 게임을 보여주는 좋은 예입니다. 현재 여러 개의 고유 한 가젯을 사용하는 27 개의 가젯 체인이 있습니다. InvokerTransformer를 사용하지 않으면 InvokerTransformer를 사용하지 않고 잠재적으로 시스템을 손상시킬 수있는 21 개 이상의 다른 가젯 체인이 있으므로 문제를 해결하지 못합니다. 설상가상으로 JRE 가젯 만 포함 된 골든 체인은 맹목적으로 비활성화하거나 제거 할 수 없습니다. 필요한 기능이 누락되어 애플리케이션이 중단 될 가능성이 높습니다.

또한  타사 구성 요소 의 transitive dependencies 은  "위험한"클래스를 식별하고 비활성화하는 문제를 더욱 복잡하게 만드는 library sprawl 을 만듭니다.

Java Deserialization 공격의 변형

이 시점에서 이러한 공격의 영향을보다 잘 이해하기 위해 세 가지 변형의 Java 역 직렬화 공격을 소개합니다.

• 시스템이 나가는 연결을 차단하는 네트워크 방화벽 뒤에 있거나 엄격한 Security Manager 정책이있는 환경에서 대상 시스템에서 데이터를 추출하기위한 Blind 역직열화 공격 .
• 가젯 체인을 데이터베이스 또는 메시지 큐에 저장하는 비동기 (또는 저장된) 역 직렬화 공격 . 가젯 체인은 대상 시스템이 데이터베이스 또는 메시지 큐에서 데이터를 읽고 deserialize 할 때 실행됩니다.
• 역 직렬화 중에 가젯 체인을 실행하지 않고 역 직렬화가 완료된 후 지연 실행 역 직렬화 공격. 이것은 일반적으로 가비지 수집 중에 finalize () 메서드 를 통해 수행 됩니다 .

알려진 DoS (Denial of Service) 역 직렬화 공격의 대부분이 Oracle과 Red Hat과 같은 다른 공급 업체에 의해 "수정되지 않음"으로 분류되어 상황이 더욱 악화됩니다. 공급 업체가 수정(fix)을 제공하지 않는 취약한 소프트웨어가있는 생산 인프라를 갖는 것은 모든 기업에게 최악의 상황입니다! 이를 악화시키는 것은 이러한 DoS 역 직렬화 공격의 대부분이 화이트리스트와 같은 간단한 기술을 사용하여 완화 될 수 없다는 것입니다.  이 공격의 좋은 예는 Wouter Coekaerts가 만든 SerialDOS 익스플로잇입니다.

올바른 해결책은 무엇입니까?

문제를 해결하고 다양한 유형의 역 직렬화 공격을 모두 중지시키는 솔루션이 있는가?  CERT 에 따르면  “개발자 는 애플리케이션 을 다시 설계해야합니다. 분명히 이러한 수정(fix)에는 이를 달성하기 위해 상당한 코드 변경, 시간, 노력 및 비용이 필요합니다. 소스 코드와 응용 프로그램의 아키텍처를 변경하는 것이 선택 할 수 있는 옵션 인 경우 이 방법이 선호됩니다. 

그러나 응용 프로그램이 자체 구성 요소에서 역 직렬화를 수행하지 않더라도 대부분의 서버, 프레임 워크 및 타사 구성 요소는 수행 합니다. 따라서 전체 스택이 기존의 필수 기능을 중단하지 않고 역 직렬화를 수행하지 않을 것이며 절대로 직렬화를 수행하지 않을 것이라고 100 % 확신하기가 매우 어렵습니다.

특히 수백 개의 배포 된 인스턴스가있는 엔터프라이즈 프로덕션 환경의 경우 소스 코드 변경을 구현할 수없는 경우가 많습니다. 일반적으로 엔터프라이즈 프로덕션 환경의 경우 코드 변경 및 몇 분 이상의 배포 시간이 필요한 보안 솔루션, 특히 직렬화 해제 취약점과 같은 중요한 취약점의 경우 허용되지 않습니다. 엔터프라이즈 솔루션은 소스 코드를 변경하지 않고도 빠르고 정확한 보호가 필요합니다.

CERT는 방화벽을 사용하여 네트워크 포트를 차단하면 경우에 따라 문제를 해결할 수 있다고 제안합니다. 그러나 대부분의 경우 적용 할 수 없습니다. 예를 들어, JBoss, WebLogic, WebSphere 등의 직렬화 해제 악용은 웹 서버의 HTTP 포트에서 실행됩니다. 즉, 해당 포트를 차단하면 서버가 쓸모 없게됩니다. 또한 이러한 솔루션은 Blind 역직열화 공격 으로부터 보호 할 수 없습니다 . 따라서 네트워크 포트를 차단하는 것은 실용적인 옵션이 아닙니다.

영향을받는 시스템 공급 업체가이 문제를 어떻게 해결 했습니까?

영향을받는 모든 소프트웨어에 대해 자세히 설명하지 않고 다음 목록 은 일부 공급 업체가 문제를 처리 한 방법을 보여줍니다.

또한 공급 업체가 문제를 자체 문제 로 인정하지 않거나  영향을받는 시스템이 더 이상 지원 되지 않는 이전 버전 이기 때문에 문제에 대한 수정안을 작성하지 않은 경우도있었습니다.

영향을 받는 시스템의 이전 또는 레거시 버전을 사용하는 고객을 Java 역직렬화 공격으로부터 어떻게 보호 할 수 있습니까?

공급 업체가 패치를 제공 할 수없고 고객이 소스 코드를 변경할 수없는 경우 그러한 생산 시스템을 어떻게 보호 할 수 있습니까? 현재 사용 가능한 옵션은 다음과 같습니다.

• 웹 응용 프로그램 방화벽 – WAF는 응용 프로그램의 입력 및 출력 만 검사 할 수 있기 때문에 응용 프로그램 컨텍스트가 없기 때문에 여기서 유용하지 않습니다. 들어오는 요청에 휴리스틱을 적용하면 오 탐지 및 오 탐지가 생성됩니다. 응용 프로그램 컨텍스트가없고 응용 프로그램 외부에서 작동하는 보안 솔루션은 역 직렬화 공격을 적절히 완화 할 수 없습니다.
• 역 직렬화를 완전히 비활성화하거나 역 직렬화되는 클래스에 블랙리스트 / 화이트리스트를 적용하는 RASP 공급 업체 및 Java 에이전트

이러한 에이전트 솔루션 중 일부는 Oracle Binary Code License Agreement를 위반하므로 프로덕션 환경에 잘못 배포되었습니다. 이것이 적절하더라도 시스템 전체에서 기본 역 직렬화를 완전히 비활성화하면 가장 사소한 Java 응용 프로그램을 제외한 모든 기능이 중단 될 수 있습니다.

블랙리스트 및 화이트리스트가 문제에 대한 나쁜 해결책 인 이유

위험한 클래스의 블랙리스트에 의존하는 보안 솔루션은 이러한 클래스가 애플리케이션에서 사용되지 않는지 확인하기 위해 애플리케이션 프로파일 링이 필요합니다. 응용 프로그램을 먼저 프로파일 링하지 않으면 응용 프로그램의 기능을 중단 할 위험이 크기 때문에 클래스를 블랙리스트에 올릴 수 없습니다. 또한 부정적인 보안 모델을 채택하면 모든 것을 블랙리스트에 올릴 수 있다는 확신을 가지지 못합니다.

차단 된 서명 목록은 지속적으로 자주 유지되어야하며 정의에 따라 게시되지 않은 제로 데이 악용을 보호하지 않습니다 . 역 직렬화 공격에 대한 솔루션으로 블랙리스트 전략을 장려하는 보안 솔루션은 Whack-a-Mole 게임을하기 때문에 실패 할 것입니다. 블랙리스트는 응용 프로그램 계층, JVM 계층 또는 네트워크 계층에서 발생하는지에 관계없이 나쁜 전략입니다.

화이트리스트는 블랙리스트보다 더 나은 방법입니다. 그러나 화이트리스트를 적용하려면 애플리케이션 프로파일 링이 다시 필요합니다. 이 경우 화이트리스트는 정말 큰 클래스 목록입니다. 이러한 큰 목록은 특히 엔터프라이즈 환경에서 관리하기가 어렵습니다. 또한 애플리케이션을 최신 릴리스로 업그레이드해야 할 때마다 프로파일링을 다시 수행하고 새 화이트리스트를 작성해야합니다. 이는 프로덕션 환경에서 새 릴리스 배포를 상당히 복잡하게 만듭니다. 이로 인해 일반적으로 화이트리스트가 업데이트되지 않아 오 탐지가 발생합니다. 마지막으로, 기업이 인프라를 지속적으로 프로파일 링하고 화이트리스트를 유지하려는 노력을 받아들이더라도 여전히 골든 가젯 체인 및 서비스 거부 역 직렬화 공격에 취약합니다.

제안 된 다른 완화 방법 은 프로세스 포크 및 파일 / 네트워크 IO를 맹목적으로 차단 (또는 화이트리스트)하는 것입니다. 이 방법으로 역 직렬화 공격의 영향을 줄일 수 있지만  데이터 유출 에 대한 맹인 공격 이나 서비스 거부 역 직렬화 공격 으로부터 보호 할 수는 없습니다 .

마지막으로 일부 연구원들은 애드혹  Security Manager 를 사용 하면 이러한 공격을 완화 할 수 있다고 제안합니다 . 그러나 첫 번째 완화 단계는 훌륭하지만 많은 한계로 인해 충분하지 않다는 것이 진실입니다.

• 보안 관리자는 쉽게 우회 되는 것으로 알려져 있습니다 .
• 역 직렬화 후에 페이로드 실행이 실행되는 지연 공격 (예 : finalize () 메서드 )은 보호하지 않습니다 .
• 대부분의 DoS 직렬화 해제 공격은 보안 관리자가 완화 할 수 없습니다.
• Security Manager를 효과적으로 활용하려면 다른 유형의 화이트리스트를 작성하고 유지해야합니다. 따라서이 접근법은 화이트리스트의 동일한 한계로 인해 어려움을 겪습니다.

새로운 솔루션

이 중요한 취약점을 해결하기 위해 더 나은 보안 솔루션이 필요합니다. 다음은 Java deserialization 공격을위한 이상적인 보안 솔루션으로 설명 할 수있는 요구 사항 목록입니다.

• 소스 코드 변경없이 작동해야합니다.
• 응용 프로그램 프로파일링 없이 작동해야합니다.
• 구성 또는 조정 없이 작동해야합니다 (블랙리스트 또는 화이트리스트 없음)
• 재배치 노력 없이 애플리케이션을 업데이트/업그레이드 할 수 있어야합니다.
• 기존 하드웨어 및 응용 프로그램 스택과 함께 작동해야합니다
• 합법적인 기능에 사용되는 한 응용 프로그램에서 "위험한" 클래스/가젯을 사용할 수 있어야합니다.
• 기존 응용 프로그램 기능 또는 이진 호환성을 중단해서는 안됩니다
• 오탐 또는 오탐을 유발해서는 안 됨
• 알려진 모든 가제트 체인 (모든 ysoserial 페이로드)으로부터 보호해야합니다.
• 구성되지 않은 게시되지 않은 제로 데이 가젯 체인으로부터도 보호해야합니다.
• 황금 가제트 체인으로부터 보호해야합니다
• 공급 업체가 "고정하지 않음"으로 분류 된 가젯 체인으로부터 보호해야합니다.
• 블라인드 역 직렬화 공격으로부터 보호해야합니다.
• 서비스 거부 역 직렬화 공격으로부터 보호해야합니다.
• Serializable 및 Externalizable 인터페이스를 모두 보호해야합니다.
• 엔드 포인트 (예 : HTTP, RMI, JMS, JNDI 등)를 통해 공격을 보호해야합니다.
• 전체 애플리케이션 스택 (JRE, 서버, 프레임 워크, 애플리케이션 및 모든 종속 라이브러리)을 보호해야합니다.
• 지연된 역 직렬화 공격 (예 : finalize ()을 통해)으로부터 보호해야합니다.
• 측면 / 저장된 역 직렬화 공격 (예 : 데이터베이스를 통한)으로부터 보호해야합니다.
• Security Manager에만 의존해서는 안됩니다
• Java의 모든 버전 및 릴리스를 지원해야합니다.

마지막으로, 솔루션은 사용하기 쉽고 배포하기 쉬울뿐 아니라 성능 오버 헤드가 발생하지 않으면 서 위의 모든 것을 달성 할 수 있어야합니다. 다시 말해, 솔루션은 생산 준비가되어 있어야합니다.

위의 요구 사항 목록은 역 직렬화 완화 솔루션의 효과와 유용성을 평가하려는 모든 사람에게 매우 도움이 될 수 있습니다.

컴파일러 기반 RASP  는 Java 객체 역 직렬화 공격을 수정 하고 위의 모든 요구 사항을 충족시키는 새로운 응용 프로그램 보안 방식입니다 .

Waratek을 사용  하고 Deserial 규칙을 켜면 전체 응용 프로그램 스택이 알려진 또는 알려지지 않은 ( 0 일 ) Java 직렬화 해제 공격으로부터 자동으로 보호됩니다 .

이는 전체 런타임 가시성을 제공하는 Waratek 내부의 역동적이고 스마트 한 구획 내에 직렬화 된 데이터를 포함함으로써 달성됩니다. 이 스마트 컴파트먼트는 가비지 수집과 같은 특정 이벤트에서 각 역 직렬화 작업 기간 동안 및 역 직렬화가 완료된 후에 활성화됩니다. 이 컴파트먼트는 합법적 인 기능을 정상적으로 실행 할 수 있지만 가제트 체인이 시스템을 남용하고 손상시키지 못하도록 격리 및 상황 별 액세스 제어를 시행합니다. 이 세분화 된 구획화로 인해 InvokerTransformer와 같은 안전하지 않은 클래스는 악의적인 가제트 체인에 의해 시스템이 손상 될 위험없이 이 기능에 의존하는 시스템에서 정상적으로 사용될 수 있습니다.

위의 모든 사항은 응용 프로그램 소스 코드를 변경하거나 구성, 프로파일 링, 오 탐지가없는 흑백 목록을 만들거나 기존 기능을 중단하지 않고도 달성 할 수 있습니다.

이 기능은 골든 가젯 체인 (JRE 전용 가젯), 블라인드 공격, 서비스 거부, 비동기 / 측면 공격 및 지연된 실행 공격도 해결합니다.

보호는 최소한의 성능 오버 헤드로 달성되며 모든 Java 릴리스에 배치 할 수 있습니다.

와라텍 정보 바로보기 ☞

https://www.waratek.com/java-deserialization-problem/

By Apostolos Giannakidis

Oracle은 Java의 직렬화 접근방식의 종료를 선언했지만, 그것이 끝은 아니다.

Oracle은 Java가 직렬화된 개체를 처리하는 방식에 큰 변화가 있음을 시사했다. 자바 플랫폼 수석 설계자인 마크 라인홀드는 1997년 현재의 직렬화 기능을 채택하기로 한 결정을 "끔찍한 실수"라고 설명한다.

라인홀드는 또한 모든 Java 취약성(취약점)의 절반 이상이 현재의 직렬화 접근방식과 연계되어 있다고 주장한다. 그럼에도 불구하고 라인홀드는 직렬화를 교체하기 위한 릴리즈 일정을 밝히지 않았다.

오라클의 현재 계획은 개발자가 원하는 직렬화 형식을 선택할 수있는 새로운 플러그인 메커니즘을 만드는 것입니다. 지원되는 포멧은 XML, JSON, YAML 그리고 기존의 직렬화와 관련된 문제 입니다. 또한 앰버 프로젝트의 일부인 데이터 클래스라는 새로운 언어의 기능을 기반으로 하는 안전한 새로운 직렬화 형식이 만들어질 것이다.

직렬화 문제가 Java를 괴롭 히고 있으며, 그 근본적인 원인을 해결하면 Java 커뮤니티에 도움이 될 것입니다. 그러나 시장에서 새로운 접근 방식의 도입이 얼마나 걸릴지, 기존의 직렬화 메커니즘을 새로운 접근 방식으로 대체하면 문제가 해결될까?

우리의 생각은 다음과 같습니다 :

1. 기존 직렬화 메커니즘을 제거하는 것이 장기적인 목표입니다. 오라클은이를 달성하기 위해 몇 년이 필요합니다. 
직렬화에 대한 현재 접근 방식은 20 년이 넘었으며, 수백 가지 Java SE의 기본 구성 요소 입니다. 대체 접근 방식이 제공 되더라도 Oracle은 몇 년 동안 이전 버전과의 호환성을 유지하기위한 옵션으로 기본 직렬화를 유지합니다.

2. 엔터프라이즈 미들웨어, 서버 및 상위 레벨 프로토콜 (예 : RMI, JMX, JMS 등)은 Java의 기본 직렬화에 의존하므로 변경하기가 매우 어렵습니다. 소프트웨어 공급 업체는 다른 기술로 전환하려면 시간과 노력이 필요할 것입니다. 이전 버전과의 호환성도 큰 문제가 될 것입니다.

3. 위의 모든 문제가 해결 되더라도 역 직렬화 취약점은 사라지지 않습니다. Java의 직렬화 결함이 유일한 결함은 아닙니다. XML 및 JSON 역 직렬화 취약점이 존재하며 기업에 실질적인 위협이 됩니다. 최근 까지도 공격자는이 취약점 (예 : CVE-2017-9805)을 악용하여 대상의 암호화 마이닝 멀웨어에 감염시켰습니다.

4. 레거시 서버와 앱은 여전히 취약합니다. 현재 대부분의 조직에서는 Java 업데이트 속도를 맞추기가 어렵습니다. 오라클의 공동 CEO 인 마크 허드는 최근 자바 사용자들은 일반적으로 몇 달에서 몇 년 뒤에 패치 작업을 한다는 사실을 인정했습니다. 실제로 버전 업그레이드 또는 앱 재 작성 시간이 더 오래 걸립니다.

5. Java가 영향을 받는 유일한 플랫폼이 아니기 때문에 조직은 여전히 직렬화 해제 문제에 대해 걱정해야합니다.
.NET, Ruby, PHP, Python 등은 역 직렬화 취약점의 영향을받습니다.

Java는 세계에서 가장 인기있는 플랫폼 언어로 널리 남아 있습니다. Java 운영을 개선하려는 모든 노력은 환영 할 것입니다.

https://www.waratek.com/serialization-is-dead-long-live-serialization/

와라텍 정보 바로보기 ☞