spring-shell-vuln

Spring4Shell: Spring core RCE 취약점

Spring은 Spring Framework에서 RCE를 확인했습니다. 팀은 이 문제에 대한 완화 가이드와 함께 성명을 방금 발표했습니다. 이 취약점은 현재 CVE-2022-22965로 추적됩니다.

Spring4Shell 취약점에 대한 몇 가지 정보가 있으며 Spring4Shell: Details and Exploit 게시물에서 세부 정보를 공유했습니다. 또한 Praetorian의 보안 팀은 CVE-2010-1622의 우회로 인해 JDK9+에서 Spring Core가 원격 코드 실행에 취약함을 확인했습니다.

처음에는 3월 30일에 시작되었으며, 취약점에 대한 첫 번째 알림은 KnownSec 404 팀의 리더인 Heige에 의해 암시되었습니다. 그는 PoC 사진과 함께 "Spring core RCE （JDK >=9"라는 경고 메시지를 트윗했습니다.

취약점에 대한 기사가 게재되면서 Heige는 트위터에서 사라졌습니다. 그 이유는 알 수 없지만 뭔가 이유가 있을 수 있습니다.

이벤트

2021년 말, 인터넷은 Apache Log4j2에서 Log4Shell이라고도 알려진 제로데이 원격 코드 실행 취약점의 등장으로 뜨거웠습니다. 이 취약점은 Alibaba Cloud 보안 팀에 의해 발견되었습니다.

- 이 취약점은 Log4Shell만큼 심각하지는 않습니다. 모든 공격 시나리오는 Java에서 Class Loader 조작 공격이 작동하는 방식의 특성상 더 복잡합니다. Spring4Shell 악용은 작동하는 PoC를 얻기 위해 깊은 Java 지식이 필요합니다. Class Loader 조작은 Log4Shell 취약점보다 이해하기 더 복잡합니다.

오늘 연구자들은 심각한 피해를 초래할 수 있는 또 다른 최악의 취약점을 발견했습니다. 이 버그는 현재 CVE-2022-22965로 추적되며, 우리는 이를 Spring4Shell이라고 부를 수 있습니다. 이 취약점은 JDK 버전 9.0 이상의 Spring Core에 존재합니다.

Spring Framework 및 파생 프레임워크의 spring -beans-*.jar 파일 또는 CachedIntrospectionResults.class

아래의 모든 세부 정보는 현재 확인되었습니다. 발생한 피해에 대해 책임을 지지 않습니다.

취약점 세부 정보 및 조사

세계에서 가장 인기 있는 Java 경량 오픈 소스 프레임워크 중 하나인 Spring은 개발자가 비즈니스 로직에 집중할 수 있게 하고 Java 엔터프라이즈 애플리케이션의 개발 주기를 단순화합니다.

악용하려면 DataBinder가 활성화된 엔드포인트(예: 요청 본문의 데이터를 자동으로 디코딩하는 POST 요청)가 필요하며, 애플리케이션의 서블릿 컨테이너에 크게 의존합니다. 예를 들어 Spring이 Apache Tomcat에 배포되면 WebAppClassLoader에 접근할 수 있으므로 공격자가 getter와 setter를 호출하여 궁극적으로 악성 JSP 파일을 디스크에 쓸 수 있습니다. 그러나 Spring이 임베디드 Tomcat 서블릿 컨테이너를 사용하여 배포되면 클래스로더는 액세스가 제한된 LaunchedURLClassLoader입니다.

그러나 JDK9 이상 버전의 Spring Framework에서는 원격 공격자가 특정 조건을 충족하는 경우 프레임워크의 매개변수 바인딩 기능을 통해 AccessLogValve 객체와 악의적인 필드 값을 얻을 수 있습니다.

현재 이 취약점을 트리거하려면 두 가지 기본 조건이 필요하다고 알려져 있습니다.
Spring MVC 프레임워크 및 JDK9 이상 사용

(1). JDK 버전 번호 확인

조직 시스템의 실행 중인 서버에서 "java -version" 명령을 실행하여 실행 중인 JDK 버전을 확인합니다. 버전 번호가 8 이하이면 이 취약점의 영향을 받지 않습니다.

(2). Spring 프레임워크 사용 여부 확인

조직 시스템 프로젝트가 war 패키지 형태로 배포된 경우 아래 단계에 따라 판단합니다.

war 패키지 압축 풀기: war 파일의 확장자를 .zip으로 변경하고 zip 파일의 압축을 풉니다.
압축 해제 디렉터리에서 spring-beans-*.jar 형식(예: spring-beans-5.3.16.jar)의 jar 파일을 검색합니다. 존재하면 비즈니스 시스템이 Spring 프레임워크를 사용하여 개발되었음을 의미합니다.
spring-beans-*.jar 파일이 없으면 압축 해제 디렉터리에서 CachedIntrospectionResuLts.class 파일이 존재하는지 검색합니다. 존재하면 비즈니스 시스템이 Spring 프레임워크를 사용하여 개발되었음을 의미합니다.

조직 시스템 프로젝트가 jar 패키지 형태로 직접 독립적으로 실행되는 경우 다음 단계에 따라 판단합니다.

jar 패키지 압축 풀기: jar 파일의 확장자를 .zip으로 변경하고 zip 파일의 압축을 풉니다.
압축 해제 디렉터리에서 spring-beans-*.jar 형식(예: spring-beans-5.3.16.jar)의 jar 파일을 검색합니다. 존재하면 비즈니스 시스템이 Spring 프레임워크를 사용하여 개발되었음을 의미합니다.
spring-beans-*.jar 파일이 없으면 압축 해제 디렉터리에서 CachedIntrospectionResuLts.class 파일이 존재하는지 검색합니다. 존재하면 비즈니스 시스템이 Spring 프레임워크를 사용하여 개발되었음을 의미합니다.

(3) 종합 조사

위의 두 가지 문제 해결 단계를 완료한 후 다음 두 조건이 동시에 충족되면 이 취약점의 영향을 받는 것으로 판단합니다:

JDK 버전 번호가 9 이상;
Spring 프레임워크 또는 파생 프레임워크를 사용.

취약점 수정 가이드

이제 Spring 팀이 취약점을 수정했으며 Spring Framework 5.3.18에 의존하는 Spring Boot 2.6.6 및 2.5.12의 최신 버전을 출시했습니다.

WAF 보호

WAF와 같은 네트워크 보호 장치에서 배포된 서비스의 실제 트래픽 상황에 따라 "class.", "Class.", ".class.", ".Class." 등의 문자열에 대한 규칙 필터링을 구현합니다. 규칙을 필터링한 후 비즈니스 운영을 테스트하여 추가적인 영향을 방지합니다.

임시 수리 조치

이 취약점의 임시 수리는 다음 두 단계를 동시에 수행해야 합니다:

@InitBinder 어노테이션을 애플리케이션 전체에서 검색하여 메서드 본문에서 dataBinder.setDisallowedFields 메서드가 호출되는지 확인합니다. 이 코드 조각의 도입이 발견되면 {"class.","Class. to the original blacklist ",".class.", ".Class."}를 추가합니다. (참고: 이 코드 조각이 많이 사용되는 경우 모든 곳에 추가해야 합니다)

애플리케이션 시스템의 프로젝트 패키지 아래에 다음 전역 클래스를 생성하고 이 클래스가 Spring에 의해 로드되도록 합니다(Controller가 위치한 패키지에 추가하는 것이 좋습니다). 클래스를 추가한 후 프로젝트를 다시 컴파일하고 패키징한 다음 기능 검증을 위해 테스트하고 프로젝트를 다시 게시해야 합니다. import org.springframework.core.annotation.Order;

 import org.springframework.web.bind.WebDataBinder;

 import org.springframework.web.bind.annotation.ControllerAdvice;

 import org.springframework.web.bind.annotation.InitBinder;

 @ControllerAdvice

 @Order(10000)

 public class GlobalControllerAdvice{ 

      @InitBinder

      public void setAllowedFields(webdataBinder dataBinder){

      String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};

      dataBinder.setDisallowedFields(abd);

      }

 }

Spring 프로젝트의 Git 저장소를 보면 Spring 개발자가 원격 코드 실행 취약점에 대한 수정을 작업 중인 것으로 보이지만 공식 확인을 기다려야 합니다.