스프링4셸 취약점이 지난 주 공개되고서 많은 보안 전문가들이 나서서 연구를 진행하고 있다. 그 결과 아직까지는 여러 가지 전제 조건이 성립되어야만 하는 것으로 결론이 나고 있다. 그래서 취약점 자체는 물론 취약점 발동 조건들도 같이 스캔하는 것이 안전하다고 한다.
[보안뉴스 문가용 기자] 이번 주 월요일 보안 업체들이 스프링 프레임워크(Spring Framework)로 만들어진 애플리케이션들 중 최근 발견된 취약점인 스프링4셸(Spring4Shell)이 있는 것들을 대략적으로 집계했다. 그 결과 적게는 수십만, 많게는 수천만 개의 애플리케이션들이 이 취약점의 영향권 아래 있음이 드러났다. 스프링4셸은 스프링셸(SpringShell)이라고 불리는 취약점으로, 관리 번호는 CVE-2022-22965이다.
스프링4셸 취약점은 지난 주 공개된 보안 취약점으로, 공개되자마자 보안 업계의 큰 관심을 끌었다. “즉각적으로 인터넷의 1/4 영역을 스캔해서 취약한 인스턴스들을 찾았을 때 약 15만 개의 장비들이 검색됐습니다. 즉 인터넷 전체에 60만 대 안팎의 장비들이 취약한 상태로 연결되어 있다는 뜻이죠.” 보안 업체 시큐리티스코어카드(SecurityScorecard)의 수석 보안 담당자인 제어드 스미스(Jared Smith)의 설명이다.
“처음에는 약 6천여 대의 장비가 취약점의 영향을 받는다는 이야기가 나왔었죠. 하지만 저희가 분석했을 때 실상은 전혀 달랐습니다. 로그4셸(Log4Shell) 취약점의 문제는 단순 스캔으로 취약한 요소들을 전부 파악할 수가 없다는 것이었습니다. 스프링4셸의 경우는 이야기가 달랐습니다. 로그4셸보다 비교도 안 될 정도로 가시적이고 직접적이니까요.” 스미스의 설명이다.
또 다른 보안 업체 소나타입(Sonatype)도 독자적으로 사태를 조사한 후 결과를 발표했다. 스프링 빈즈(Spring Beans) 요소를 디펜던시로서 활용한 애플리케이션의 81%가 취약할 수 있다는 내용이다. 그러면서 소나타입은 “수백만~수천만 명의 사용자들에게 영향이 있을 수 있다”고 예측했다. 물론 이 숫자는 아직까지 추정치이긴 하다.
스프링4셸은 매우 중대한 문제라고 보안 업계는 받아들이고 있다. 다만 지금 당장 인터넷 전체가 커다란 위협에 뒤흔들리고 사이버 생태계가 파괴될 정도로 심각한 문제는 아니다. 소나타입의 CTO인 일카 투루넨(Ilkka Turunen)은 4월 4일자 블로그 게시글을 통해 “사건 초기인데도 로그4j 사태 때와는 확연히 다른 업데이트 속도가 나타나고 있다”고 밝혔다. “그만큼 서두르지 않는다는 것이죠. 특정 상황과 조건이 맞아야 익스플로잇이 가능한 취약점이기 때문일 거라고 봅니다.”
투루넨의 설명처럼 스프링4셸 취약점에 대한 패치가 비교적 느리게 진행되는 까닭은 현재 공개된 익스플로잇 코드가 여러 가지 조건이 성립되어야만 작동하기 때문이다. 실제 익스플로잇 공격이 발생할 가능성이 그리 높지 않다고 여러 조직들이 판단하고 있는 것이다. 그 조건이란 애플리케이션이 JDK 9 이상 버전에서 구축된 아파치 톰캣(Apache Tomcat) 서버에 설치되어야 한다는 것이다. 또한 스프링 WebMVC와 스프링 WebFlux 요소들을 통해 스프링 빈즈 패키지가 사용되어야만 한다.
투루넨은 “익스플로잇에 필요한 조건이 너무나 많다”며 “확실히 실제 공격에 노출된 장비나 인스턴스들이 줄어들 수밖에 없다”고 설명한다. “실제 스프링4셸 공격에 대해 걱정해야 하는 경우는 그리 많지 않을 수 있습니다. 하지만 대형 프로젝트들의 경우 레거시 장비나 소프트웨어를 포함하고 있을 때가 많습니다. 프로젝트 관리자나 참여 개발자들도 하나하나 파악하지 못할 정도로요. 그런 경우 취약점이 숨겨져 있을 수 있습니다.”
보안 업체 제이프로그(JFrog)도 독자적인 조사와 분석을 통해 비슷한 결론을 내렸9다. “자바 9 버전부터는 새로운 API가 도입됐고, 이 때문에 스프링의 보호 장치를 피해 임의의 값을 ClassLoader에 부여하는 게 가능해졌습니다. 이것이 문제의 근원이라고 생각합니다. 하지만 익스플로잇을 가능하게 하는 설정이 ‘디폴트 설정’이 아니기 때문에 취약한 스프링 버전을 사용했다고 하더라도 애플리케이션이 취약한 상태가 아닐 수 있습니다.”
제이프로그의 보안 연구원인 샤카르 메나쉬(Shachar Menashe)는 “스프링4셸 취약점 자체는 심각한 문제이긴 하지만, 이것이 실제로 취약점으로서 발동되려면(즉, 조직들이 위험해지려면) 여러 가지 조건이 맞아떨어져야 해서 실제 위험하다고 볼 수 있는 조직은 많지 않을 수 있다”고 지적한다. “즉 취약점을 스캔하는 걸 넘어, 자바 애플리케이션의 구축 환경과 조건을 모든 조직들이 개별적으로 점검해야 한다는 뜻입니다.”
시큐리티스코어카드는 내부 네트워크 스캔과 외부 스캔을 모두 실시할 것을 권장한다. “취약점만이 아니라 취약점을 취약하게 만드는 조건들이 성립되어 있는지도 스캔해야 합니다. 또한 장기적으로는 소프트웨어가 어떤 재료들로 구성되어 있는지를 추적하고 이를 보관해 두어야 합니다. 그래야 로그4셸과 스프링4셸과 같은 취약점이 발생했을 때 금방 찾아낼 수 있습니다.”
또한 “아직 안심할 때가 아니”라는 것도 강조됐다. “지금 공개된 익스플로잇이 전부가 아닐 겁니다. 더 많은 공략법이 나오고, 어쩌면 지금 우리가 알고 있는 전제조건을 무력화시키는 공격 기법도 나올 수 있습니다. 그러니 지금은 실제 위험성이 낮아 보인다고 해도 방심해서는 안 됩니다.”
3줄 요약
1. 스프링4셸 취약점에 대한 연구가 보안 업체별로 계속해서 이어지고 있음.
2. 현재까지 연구 결과는 “중대한 문제가 맞긴 한데 실제로 위험한 경우는 그리 많지 않을 듯.”
3. 취약점 자체를 스캔하면서 동시에 취약점 발동 조건에 대한 스캔도 병행하는 게 안전.
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 이번 주 월요일 보안 업체들이 스프링 프레임워크(Spring Framework)로 만들어진 애플리케이션들 중 최근 발견된 취약점인 스프링4셸(Spring4Shell)이 있는 것들을 대략적으로 집계했다. 그 결과 적게는 수십만, 많게는 수천만 개의 애플리케이션들이 이 취약점의 영향권 아래 있음이 드러났다. 스프링4셸은 스프링셸(SpringShell)이라고 불리는 취약점으로, 관리 번호는 CVE-2022-22965이다.
[이미지 = utoimage]
스프링4셸 취약점은 지난 주 공개된 보안 취약점으로, 공개되자마자 보안 업계의 큰 관심을 끌었다. “즉각적으로 인터넷의 1/4 영역을 스캔해서 취약한 인스턴스들을 찾았을 때 약 15만 개의 장비들이 검색됐습니다. 즉 인터넷 전체에 60만 대 안팎의 장비들이 취약한 상태로 연결되어 있다는 뜻이죠.” 보안 업체 시큐리티스코어카드(SecurityScorecard)의 수석 보안 담당자인 제어드 스미스(Jared Smith)의 설명이다.
“처음에는 약 6천여 대의 장비가 취약점의 영향을 받는다는 이야기가 나왔었죠. 하지만 저희가 분석했을 때 실상은 전혀 달랐습니다. 로그4셸(Log4Shell) 취약점의 문제는 단순 스캔으로 취약한 요소들을 전부 파악할 수가 없다는 것이었습니다. 스프링4셸의 경우는 이야기가 달랐습니다. 로그4셸보다 비교도 안 될 정도로 가시적이고 직접적이니까요.” 스미스의 설명이다.
또 다른 보안 업체 소나타입(Sonatype)도 독자적으로 사태를 조사한 후 결과를 발표했다. 스프링 빈즈(Spring Beans) 요소를 디펜던시로서 활용한 애플리케이션의 81%가 취약할 수 있다는 내용이다. 그러면서 소나타입은 “수백만~수천만 명의 사용자들에게 영향이 있을 수 있다”고 예측했다. 물론 이 숫자는 아직까지 추정치이긴 하다.
스프링4셸은 매우 중대한 문제라고 보안 업계는 받아들이고 있다. 다만 지금 당장 인터넷 전체가 커다란 위협에 뒤흔들리고 사이버 생태계가 파괴될 정도로 심각한 문제는 아니다. 소나타입의 CTO인 일카 투루넨(Ilkka Turunen)은 4월 4일자 블로그 게시글을 통해 “사건 초기인데도 로그4j 사태 때와는 확연히 다른 업데이트 속도가 나타나고 있다”고 밝혔다. “그만큼 서두르지 않는다는 것이죠. 특정 상황과 조건이 맞아야 익스플로잇이 가능한 취약점이기 때문일 거라고 봅니다.”
투루넨의 설명처럼 스프링4셸 취약점에 대한 패치가 비교적 느리게 진행되는 까닭은 현재 공개된 익스플로잇 코드가 여러 가지 조건이 성립되어야만 작동하기 때문이다. 실제 익스플로잇 공격이 발생할 가능성이 그리 높지 않다고 여러 조직들이 판단하고 있는 것이다. 그 조건이란 애플리케이션이 JDK 9 이상 버전에서 구축된 아파치 톰캣(Apache Tomcat) 서버에 설치되어야 한다는 것이다. 또한 스프링 WebMVC와 스프링 WebFlux 요소들을 통해 스프링 빈즈 패키지가 사용되어야만 한다.
투루넨은 “익스플로잇에 필요한 조건이 너무나 많다”며 “확실히 실제 공격에 노출된 장비나 인스턴스들이 줄어들 수밖에 없다”고 설명한다. “실제 스프링4셸 공격에 대해 걱정해야 하는 경우는 그리 많지 않을 수 있습니다. 하지만 대형 프로젝트들의 경우 레거시 장비나 소프트웨어를 포함하고 있을 때가 많습니다. 프로젝트 관리자나 참여 개발자들도 하나하나 파악하지 못할 정도로요. 그런 경우 취약점이 숨겨져 있을 수 있습니다.”
보안 업체 제이프로그(JFrog)도 독자적인 조사와 분석을 통해 비슷한 결론을 내렸9다. “자바 9 버전부터는 새로운 API가 도입됐고, 이 때문에 스프링의 보호 장치를 피해 임의의 값을 ClassLoader에 부여하는 게 가능해졌습니다. 이것이 문제의 근원이라고 생각합니다. 하지만 익스플로잇을 가능하게 하는 설정이 ‘디폴트 설정’이 아니기 때문에 취약한 스프링 버전을 사용했다고 하더라도 애플리케이션이 취약한 상태가 아닐 수 있습니다.”
제이프로그의 보안 연구원인 샤카르 메나쉬(Shachar Menashe)는 “스프링4셸 취약점 자체는 심각한 문제이긴 하지만, 이것이 실제로 취약점으로서 발동되려면(즉, 조직들이 위험해지려면) 여러 가지 조건이 맞아떨어져야 해서 실제 위험하다고 볼 수 있는 조직은 많지 않을 수 있다”고 지적한다. “즉 취약점을 스캔하는 걸 넘어, 자바 애플리케이션의 구축 환경과 조건을 모든 조직들이 개별적으로 점검해야 한다는 뜻입니다.”
시큐리티스코어카드는 내부 네트워크 스캔과 외부 스캔을 모두 실시할 것을 권장한다. “취약점만이 아니라 취약점을 취약하게 만드는 조건들이 성립되어 있는지도 스캔해야 합니다. 또한 장기적으로는 소프트웨어가 어떤 재료들로 구성되어 있는지를 추적하고 이를 보관해 두어야 합니다. 그래야 로그4셸과 스프링4셸과 같은 취약점이 발생했을 때 금방 찾아낼 수 있습니다.”
또한 “아직 안심할 때가 아니”라는 것도 강조됐다. “지금 공개된 익스플로잇이 전부가 아닐 겁니다. 더 많은 공략법이 나오고, 어쩌면 지금 우리가 알고 있는 전제조건을 무력화시키는 공격 기법도 나올 수 있습니다. 그러니 지금은 실제 위험성이 낮아 보인다고 해도 방심해서는 안 됩니다.”
3줄 요약
1. 스프링4셸 취약점에 대한 연구가 보안 업체별로 계속해서 이어지고 있음.
2. 현재까지 연구 결과는 “중대한 문제가 맞긴 한데 실제로 위험한 경우는 그리 많지 않을 듯.”
3. 취약점 자체를 스캔하면서 동시에 취약점 발동 조건에 대한 스캔도 병행하는 게 안전.
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
