[Security News] Log4Shell(로그4셸)과 닮은꼴?
웹 앱 프레임워크인 스프링에서 나온 Spring4Shell(스프링4셸)

지난 12월 세상은 역대 최악의 취약점을 찾아냈습니다. Log4j에서 발견된 Log4Shell 취약점이 바로 그것입니다. 그리고 3월, 또 다른 취약점이 웹 앱 프레임워크에서 발견됐고, 스프링4셸(Spring4Shell)이라는 이름이 붙었습니다. 또 다른 악몽의 시작일까요?

인기 높은 웹 애플리케이션 개발 프레임워크인 스프링(Spring)에서 제로데이 취약점이 발견됐습니다. 많은 개발자들이 스프링을 사용해 앱을 개발하기 때문에 수많은 웹 애플리케이션들이 취약할 것으로 예상되고 있습니다. 이 제로데이 취약점은 원격 공격을 가능하게 하는 성질을 가지고 있기 때문에 스프링과 관련된 웹 애플리케이션들의 시급한 점검이 필요합니다.

[이미지 = unsplash]

일부 보안 업체에서는 이 취약점을 스프링4셸(Spring4Shell) 혹은 스프링셸(SpringShell)이라고 부르고 있고, 이 이름은 현재 빠르게 퍼져나가는 중입니다. 요 하루 이틀 정도, 보안 업계는 스프링4셸 취약점을 분석하느라 분주한 시간을 보내고 있습니다. 특히 스프링4셸이 새로 생긴 취약점인지 혹은 오래된 취약점과 관련되어 있는지 확인하는 작업이 한창 진행 중에 있습니다. 보안 업체 프레토리안(Praetorian)과 플래시포인트(Flashpoint)는 독립적으로 분석해 “새롭게 발생한 취약점”이라는 결론을 똑같이 내렸습니다. 또한 아파치 톰캣(Apache Tomcat) 서버에 구축되었을 경우 원격 익스플로잇이 가능하다는 사실도 똑같이 발표했습니다.

스프링4셸 취약점에는 아직 CVE 번호가 붙지 않았습니다. 하지만 앞으로 장기간의 패치 작업이 이뤄져야 할 것으로 예상됩니다. 프레토리안의 CTO인 리차드 포드(Richard Ford)는 “취약한 채로 남겨둔 웹 애플리케이션의 경우(스프링으로 개발된 앱들 중), 원격 익스플로잇의 가능성을 내재시키는 것과 다름이 없다”고 경고합니다. “익스플로잇은 매우 간단한데, 그 파급력은 광범위합니다. 물론 지켜져야 하는 조건이 있는데, 이 조건이 성립하지 않는 환경에 있다고 판단되더라도 일단 패치를 하는 것이 좋습니다.”

스프링 프레임워크에서는 이번 주 두 개의 다른 취약점들이 발견되기도 했습니다. 스프링 클라우드(Spring Cloud)의 취약점인 CVE-2022-22963과 스프링 익스프레션(Spring Expression)의 취약점인 CVE-2022-22950이 바로 그것입니다. 보안 업계는 스프링4셸과 이 두 가지 취약점들과의 관련성을 분석하고 있는데, 아직까지는 무관한 것으로 분석되고 있습니다. 프레토리안과 플래시포인트도 같은 결론을 내리고 있습니다.

스프링은 VM웨어(VMware)가 소유하고 운영하는 브랜드 중 하나입니다. 프레토리안에 따르면 현재 VM웨어는 로그4셸에 대한 패치를 준비 중에 있다고 합니다. 플래시포인트의 경우 다크웹을 조사 중에 있는데, 아직까지 해커들 사이에서 스프링4셸에 대한 이야기가 나오고 있지는 않다고 합니다. “현 시점까지는 실제 공격을 위한 익스플로잇 시도는 발견되지 않고 있습니다. 여태까지 분석된 바에 의하면 공격자들이 이 취약점을 익스플로잇 하려면 DeserializationUtils라는 걸 사용하는 웹 앱 인스턴스들을 먼저 찾아내야 합니다. 그런데 자바 개발자들 대부분 DeserializationUtils이 위험하다는 건 상식처럼 알고 있습니다.”

포드는 이것이 두 가지 의미를 가지고 있다고 풀이합니다. “개발자들이 위험하다고 알고 있는 것이니 어지간하면 발견되지 않을 것이라는 뜻이 됩니다. 공격의 전제 조건이 성립되기 힘들 수 있다는 뜻이죠. 그런데 만약 발견된다면 어떨까요? 로그4셸 익스플로잇 외에 다른 위험 가능성, 즉 DeserializationUtils가 원래 가지고 있던 위험성까지도 복합적으로 작용하게 된다는 뜻이 됩니다. 이 취약점 익스플로잇이 가능한 환경이면 보이는 것보다 더 많은 위험이 잠재되어 있을 수도 있습니다.”

삭제된 트위터 게시글

스프링4셸 취약점이 보안 업계에 널리 알려지게 된 건 한 중국 보안 전문가가 개념증명용 공격 시연 화면을 캡쳐해 공유한 이후부터 입니다. 어찌보면 개념증명용 익스플로잇 코드가 선공개되었다고 볼 수 있습니다. 하지만 그 중국 보안 전문가는 게시글을 재빨리 삭제했습니다. 중국 내에서는 정부의 허락 없이 취약점 정보를 공개하는 게 큰 범죄인데, 그것 때문인 것으로 보입니다. 하지만 3월 30일, 사이버 공격 및 멀웨어 정보 공유 포럼인 VX-언더그라운드(VX-Underground)가 삭제된 게시글의 내용을 퍼트리기 시작했습니다.

프레토리안의 수석 엔지니어인 안토니 윔즈(Anthony Weems)는 “(중국 보안 전문가가 올린 스크린샷의 원본) 스크린샷을 보고 나니 공격을 간단히 시연할 수 있었다”고 말합니다. “아직까지 저희가 분석한 바에 의하면 취약한 스프링 애플리케이션들이 톰캣에 임베드 되어 있어야만 익스플로잇이 가능한 것으로 보입니다. 하지만 스프링붓(Spring Boot)을 사용해 임베드 된 경우라면 익스플로잇이 불가능합니다. 스프링붓을 사용하는 건 꽤나 흔한 기법이기도 합니다. 다행인 지점이죠.”

한 가지 보안 전문가들을 우려스럽게 하는 건 지난 12월에 마찬가지로 자바 생태계에서 발견된 로그4셸(Log4Shell) 취약점과의 관련 가능성입니다. 실제 두 취약점(로그4셸과 스프링4셸) 사이에는 유사성이 존재합니다. “인기 많은 프레임워크 혹은 라이브러리(전자는 스프링, 후자는 로그4j)가 알려진 것 외에 다른 특성도 가지고 있다는 점에서 두 취약점은 비슷합니다. 자바 환경에서 사용된다는 것도 비슷한 점이고요. 하지만 그것 외에는 크게 비슷할 것이 없습니다.”

Log4Shell 취약점이 훨씬 더 심각

Log4Shell 취약점에는 ‘역대 최악의 취약점’이라는 수식어가 따라붙습니다. 여기에 거의 모든 보안 전문가들이 동의합니다. 스프링4셸은 그와 비슷한 수준도 아닙니다. “파급력이라는 측면에서 둘은 비교 불가입니다. 심지어 스프링4셸 익스플로잇 난이도가 로그4셸의 그것보다 훨씬 높아요. 스프링4셸은 공격하려면 공격자가 미리 애플리케이션의 엔드포인트 주소도 알고 있어야 합니다. 앞서 언급한 전제 조건들도 따라붙고요. 둘이 어쩌다가 이름이 비슷하게 붙었는데, 차이는 확연합니다.”

출처 : 보안뉴스, 정보유출, DLP, GRADIUSDLP, 그라디우스, 데이터유출, 정보유출방지, 내부정보유출방지, 취약점, 시큐어코딩, 취약점진단, 취약점점검, 스패로우, sparrow, vada, 시스템취약점진단