01. 개요

2022년 3월 30일, JAVA 플랫폼에서 매우 널리 사용되는 오픈소스 프레임워크인 Spring Framework 취약점이 공개되었다. Spring Core Framework에서 노출된 'class' 객체의 자식 객체인 'class.module.classLoader' 매개변수에 접근하면 ‘AccessLogValve’ 객체를 통해 웹쉘을 업로드하고 원격코드 실행 취약점으로 연결되게 된다. 2022년 6월 2일 미국 정보 보안 전문 업체 볼렉시티(Volexity)는 중국 APT 그룹인 하프늄(Hafnium)에서 제작된 것으로 추정되는 China Chopper 웹쉘이 Atlassian Confluence Server에 업로드되어 조사 중 취약점이 발견되어 조치된 바 있다. 웹쉘 공격의 원인이 파일 업로드나 SQL Injection과 같이 웹 프로그래밍 언어에 제한되던 것에 반해 최근에는 오픈소스 프레임워크, CMS(Contents Management System)등 소프트웨어 생태계 변화에 따라 다양해지는 것을 알 수 있다.

[그림 1]와 같이 마이크로소프트의 Microsoft 365 Defender에서 발표한 ‘Web shell attacks continue to rise’에 따르면 2022년과 2021년에 발견된 웹쉘은 14만 건으로 2019년부터 2년간 발생된 웹쉘 평균 개수의 7만 7천 건에 비해 2배 증가한 수치다. 웹쉘 공격이 증가하고 있는 원인을 분석해 보면 소프트웨어 생태계의 복잡성의 증가에 따라 신규 취약점 등을 악용하지 않더라도 간단한 공격만으로도 쉽게 공격할 수 있기 때문이라고 판단할 수 있다.

따라서 이번 호에서는 웹쉘 공격에 대해서 다시한번 분석해보고 최근 웹쉘 공격이 악용되는 사례를 분석하여 현실적인 대안을 모색해보고자 한다.

02. Web Shell 공격 표면(Attack Surface) 및 공격 방식

웹쉘은 웹 서비스를 구동하기 위한 웹서버 환경에서 지원 가능한 웹 애플리케이션 언어를 기반으로 동작되는 파일을 의미하여, [표 1]과 같은 확장자 목록의 파일을 이용해 정상∙비정상적인 접근 경로로 접근하여 서버 정보 및 권한을 탈취하는 기능을 수행하게 된다.

웹쉘은 주로 외부망에 있는 공격자가 시스템 내부에 명령 수행을 하기 위한 목적으로 사용되기 때문에 [표 2]와 같이 시스템 명령을 사용할 수 있는 함수를 포함하고 있거나, 업로드된 웹쉘 파일을 숨기거나 기능 분석을 저해하기 위한 목적으로 암호화나 압축을 수행하게 된다.

웹쉘은 시스템 제어 및 장악을 통한 시스템 가용성 저해나 데이터 탈취 등을 목적으로 하고 있기 때문에 단발적인 공격으로 그치지 않고 다수 접속하여 시스템을 제어하는 데 사용된다. 일반적으로 웹쉘 파일을 업로드하기 위한 공격 방식은 웹 페이지에 구현되어 있는 파일 업로드 기능을 이용하여 업로드하게 되기 때문에 SmartEditor, DaumEditor, Namo Crosseditor 등의 에디터 취약점은 웹쉘이 업로드되는데 직접적으로 영향을 미치게 된다.

웹쉘을 업로드하는 방식이 반드시 파일 업로드 기능만 이용되는 것은 아니다. 파일 업로드 기능이 존재하는 경우 비정상적인 파일 업로드 공격 시도를 대응하기 위해 파일 확장자를 필터링하거나 파일 사이즈를 제한하는 등의 보안조치를 수행하게 된다. 업로드 기능이 존재하지 않아도 서버 환경에 파일을 업로드할 수 있는 방법은 많다. 이때 사용되는 것이 앞서 설명한 프레임워크나 CMS 이외에도 다수의 취약점을 이용하는 방법이다.

웹 서비스를 지원하기 위한 목적으로 사용되는 Wordpress, Drupal, Aapceh Struts2, Spring, 전자정부 프레임워크 등의 웹 개발 프레임워크 취약점을 사용하거나, IIS 파일 확장자 우회와 같이 WEB/WAS의 취약점 등을 이용할 수 있게 된다. 기본적인 웹 취약점 중에는 Cross-Site Scripting(XSS), RFI(Remote File Inclusion) 등을 사용하는 경우도 있다.

웹쉘 파일이 업로드되기 위해서는 파일 형태에서도 변화를 줄 수 있다. 일반적인 웹 프로그래밍 확장자로 제작된 파일을 업로드하는 경우에는 필터링 되는 경우가 많기 때문에 메모리나 이미지 파일 등에 덮어쓰기 해도 무관한 영역을 이용하여 웹쉘 파일을 업로드하는 경우가 있다. ASPXSpy, b374k-shell, JspSpy 등 웹 프로그래밍 언어별로 유명한 웹쉘 파일의 경우에는 파일 기능을 아무도 사용하지 못하도록 암호화하는 등 다양한 형태로 기능을 확장하고 있다. 다음 장에서는 웹쉘 공격을 하기 위한 실제 공격 사례를 분석해 보고자 한다.

03. 최신 Web Shell 공격 사례 분석 및 대응방안

웹 어플리케이션 언어의 시큐어코딩 미흡으로 인한 파일 업로드 공격 사례가 다수의 보고서에서 분석 된 바 있기 때문에 워드프레스나 드루팔(Drupal) 과 같은 오픈소스 기반의 CMS 취약점을 악용한 사례를 설명하고자 한다. 이러한 변화는 웹쉘 공격을 수행할 수 있는 접점이 확대되었을 뿐만 아니라 네트워크 패킷 암호화, 소스코드 인코딩 및 난독화 등을 통해 웹쉘 파일을 인지할 수 있는 방법이 점점 어려워진다는 것을 의미하게 된다. 이번 파트에서는 특히 파일리스 웹쉘 공격과 인젝션 웹쉘 공격 사례를 분석해 보고 대응 방안을 모색해 보고자 한다.

1) Fileless Web shell Attack

최근 PHP 언어 기반의 CMS 중 하나인 드루팔(Drupal)에서 파일리스(Fileless) Webshell 공격을 설명하고자 한다. 해당 공격은 PHP를 실행할 수 있는 드루팔 7.x 버전을 사용하는 대상을 기반으로 공격이 발생된다. 드루팔에 웹쉘을 삽입해서 공격하기 때문에 파일리스 웹쉘 공격을 수행할 수 있게 된다. 피해 시스템에서 웹쉘 파일을 검색한다고 해도 파일을 검색할 수 없기 때문에 피해 사실을 인지하지 못하게 하는데 유용하게 된다.

드루팔에서 발생한 파일리스 웹쉘 공격의 경우에는 공격자가 파일을 저장하는 형태가 아닌 관리자 페이지에 접근하고, 블록 설정 메뉴에서 PHP 코드를 반환하는 기능을 이용하여 데이터베이스에 웹쉘 코드를 삽입하는 방식으로 이루어졌다.

웹쉘 코드는 드루팔의 웹 페이지를 구성하는 블록의 pages 컬럼에 삽입되었고, 해당 페이지에 다시 접근하게 되면 데이터베이스에 저장되어 있던 웹쉘이 정상적으로 실행되는 것을 확인할 수 있다.

이렇게 블록에 포함되는 내용은 웹 서버 루트 디렉터리 하위에 파일 형태로 저장되지 않고 데이터베이스에 저장된 후 실행되는 구조이기 때문에, 별도의 웹쉘 파일과 관련된 정보가 남지 않아 탐지나 추적에 매우 큰 어려움이 존재한다. 공개된 드루팔 취약점(관리자 권한 탈취, 원격 코드 실행 등)이 다수 존재함에 따라 PHP가 실행되지 않는 버전(9.x 버전 이상)을 사용하고 최신 보안 패치를 적용하는 등의 대응이 필요하다.

공격에 사용된 ALFA TEaM shell은 PHP 언어 환경에 특화되어 있는 웹쉘이다. ALFA TEam shell은 2017년에 최초로 사용되기 시작하여 2022년 9월 기준 4.1버전까지 나온 것으로 확인되었으며, 단일 PHP 파일 내에 많은 함수를 포함하고 있는 “all-in-one” 웹쉘로 알려져 있다. Alfa-TEaM-shell의 경우에는 변수명, 페이로드 등의 코드가 모두 난독화되어 있어 일반적으로 웹쉘을 검색할 때 사용하는 PHP 함수나 OS 명령어 실행 등에 대한 코드 검색에 어려움이 존재한다,

Alfa-TEaM-shell의 일부 기능을 실행해 보면 패널의 기능을 선택하거나 터미널에서 명령어를 전송할 때, 네트워크 Base64로 인코딩된 상태로 패킷이 전송되는 특징이 존재하며, Alfa TEaM shell에는 CMS Hijacker, Add New Admin(CMS 전용) 등 CMS 관련 기능이 다수 존재하는 것이 특징이다.

2) Injection Web Shell Attack

중국의 APT 그룹인 “Driftingcloud”가 방화벽에 웹쉘을 삽입하여 공격한 사례를 설명하고자 한다. 공격자는 CVE-2022-1040 취약점을 이용하여 방화벽을 공격하였으며, 처음 웹쉘을 삽입하여 방화벽을 공격한 후, 지속성을 유지하기 위해 또 다른 웹쉘을 삽입하여 공격을 수행한 것으로 알려졌다.

공격자는 방화벽의 정상적인 구성요소인 Class 파일에 악의적인 코드를 삽입하고 직접 생성하여 배포하였다. 또한, 추적을 어렵게 하기 위해 Class 파일의 파일스탬프를 변경하여 같은 폴더의 다른 파일들과 마지막 수정 시간을 동일하게 만들었다.

또한, 변조된 class 파일을 살펴보면, ① Request URI 또는 Accept 헤더에 “Applicationssid” 문자열이 포함되어 있는지 확인하고, ② 문자열이 포함되어 있으면 서버 Request가 POST 인지 확인한다. 마지막으로 ③의 부분은 ①과 ②의 조건이 만족하면 AES 암호화와 base64로 encoding 되어 있는 POST 본문을 string var13의 변수 값(a918c0e8d8153bfc)을 이용하여 decoding 한다.

[그림 11]에서 변조된 Class 파일의 코드는 Behinder Web shell 코드와 비슷한 것으로 Behinder Webshell은 Atlassian Confluence zero-day(CVE-2022-26134) 공격에서도 사용되었던 웹쉘로 알려져 있다. 실제 Behinder Webshell을 살펴보면 Class 파일에서 본 것처럼 L2의 Key 값을 사용하여 AES 암호화와 base64로 encoding 되어 있는 POST 본문을 decoding 한다.

Behinder 웹쉘에 직접 접근해 본 결과, 네트워크 패킷을 보면 페이지에 접근할 때, POST 방식으로 난독화 된 본문이 존재하는 것을 확인할 수 있다.

또한, Behinder은 .jar 파일 형태의 C&C 패널을 통해 피해자의 웹 서버에 [그림 13]과 같은 코드로 구성된 웹쉘 파일을 업로드하여 컨트롤 한다는 특징이 있다.

추가적으로 공격자는 원격에서의 접근을 위해 VPN 사용자 계정을 생성한 후, 다른 사용자의 자격 증명(Credential)과 세션 쿠키 값 탈취를 목표로 웹사이트에 대한 DNS 응답을 수정했다. 이후 추가적인 공격과 정보 탈취를 위해 Linux에서 제공하는 Weevely라는 도구를 이용하여 난독화 된 두 번째 웹쉘을 업로드하였다.

해당 웹쉘 공격은 일반적으로 발생하는 공격 표면과 다르게 웹 서버, 데이터베이스가 아닌 악의적인 침입을 방어하기 위해 만들어진 방화벽에 웹쉘을 업로드한 특이한 유형이다. 또한, 일반 웹쉘 파일 업로드가 아닌 기존에 방화벽에 존재하는 정상적인 class 파일과 동일한 파일명을 사용하여 공격을 수행하였으며, Behinder 웹쉘과 같이 네트워크 패킷이 난독화 되어 있는 공격으로 인하여 추적 및 탐지가 굉장히 어렵다.

04. Web Shell 대응전략

지금까지 웹쉘이 사용된 취약점과 최근 공격에 사용되었던 웹쉘을 살펴보았다. 앞서 살펴본 바와 같이 웹쉘 공격은 IoT 장비, 방화벽, CMS 등 다양한 공격표면에 사용되고 있다. 또한 웹쉘 공격은 웹 서비스, 웹 서버 등에 존재하는 다양한 취약점을 이용하여 정보수집과 공격 지속성을 위해 사용되고 있다. 이러한 웹쉘 공격에 대응하기 위해서는 개발 단계에서부터 유지 보수까지 △ 기술적 측면과 △ 관리적 측면 등 다양한 부분에서 대응전략을 수립하여야 한다.

1) 사전 대응 관점에서의 전략

먼저, ‘사전 대응 관점’에서 바라본 대응 전략이다. 웹쉘의 경우에는 다양한 공격의 첫 수단이자 공격 지속성을 유지하기 위한 수단으로 사용되기 때문에, 웹쉘 공격이 행해지는 공격 표면에 대한 사전 대응 관점에서의 전략 수립되어야 한다. 특히, 공격자의 초점이 점차 어플리케이션 계층으로 이동함에 따라 소프트웨어 보호가 중요하다.

소프트웨어를 보호하기 위해서는 설계, 구현, 테스트 단계에 보안 설계 기준을 적용하여야 한다. KISA에서 발간한 ‘소프트웨어 개발 보안 가이드’ 기반으로 보면 설계 단계에서의 보안 설계 기준은 크게 △ 입력 데이터 검증 및 표현, △ 보안 기능, △ 에러 처리, △ 세션 통제 등으로 분류할 수 있으며, 지금까지 살펴본 웹쉘 공격의 경우에는 외부에서 전달되는 입력 값에 대한 검증이 미흡하여 발생하는 문제로 볼 수 있다.

이에 따라, 입력 값 검증 미흡으로 발생할 수 있는 취약점들을 확인하여 그에 맞는 대응을 진행한다면 웹쉘 공격의 원인을 차단하고 피해를 최소화할 수 있을 것이다. 다음 [표 6]은 입력 데이터 검증 및 표현에서 웹쉘 공격의 원인이 되는 취약점과 대응 방안을 일부 재구성하여 정리한 것이다.

웹쉘 공격의 원인이 되는 취약점들에 대한 대응을 위해서는 개발 및 구현 단계에서 시큐어 코딩 적용도 매우 중요하다. 시큐어 코딩 적용은 [표 6]에 작성된 모든 취약점에 대하여 대응해야 하고, 시큐어 코딩을 적용 방식에는 다양한 방법이 존재하지만, 실제 개발 환경에서 무수히 많은 코드에 대하여 일일이 수작업을 통해 시큐어 코딩을 적용하는 것은 쉽지 않은 일이다.

따라서, 좀 더 안전하고 빠른 시큐어 코딩 적용을 위해 시큐어 코딩 점검 도구를 사용하는 것을 추천한다. 먼저 시큐어 코딩 점검 도구에는 다양한 상용 도구와 무료 도구가 존재하지만, 이번 파트에서는 무료 라이센스 도구 중 국내에서 개발할 때 가장 많이 사용하는 JAVA 코드를 점검할 수 있는 △ Spotbugs 그리고 이것과 함께 사용하면 좋은 △ Find Security Bugs 플러그인을 선정하여 설명하고자 한다.

먼저, ‘Spotbugs’는 오픈 소스 기반의 시큐어 코딩 점검 도구이며, Linux, Windows, MacOS 운영체제를 지원하고 GUI 기반의 프로그램 방식과 Eclipse, NetBeans, IntelliJ IDEA, SonarQube 등에 대하여 플러그인 방식을 지원하여 높은 확장성을 가지고 있다.

해당 도구는 JAVA 바이트 코드 (byte code)를 정적 분석하여 버그 패턴을 발견하고 Java 프로그램에서 발생 가능한 100여 개의 잠재적인 에러에 대하여 scariest, scary, troubling, concern 등의 4등급으로 구분하여 탐지하고 결과를 XML로 저장할 수 있도록 지원하고 있다. Spotbugs에서는 Bad practice, Correctness, Experimental, Experimental, Internationalization 등 10개 이상의 카테고리와 400개가 넘는 규칙이 등록되어 있고 룰셋(ruleset)의 커스터마이징이 가능하다.

그러나 Spotbugs는 단순히 코드에 대한 오류를 탐지해 주기 때문에 보안 적용에 대한 내용이 부족해 보인다. 이러한 단점을 보안하기 위해 Spotbugs와 함께 사용하면 좋은 Find Security bugs 플러그인에 대하여 설명하도록 하겠다.

Find Security Bugs는 자바 웹 애플리케이션에 대한 보안 감사를 지원하는 플러그인이다. 832개 이상의 API 시그니처를 활용하여 OWASP TOP 10 및 CWE 커버리지가 가능한 141개의 버그 패턴을 탐지할 수 있으며, 최근에는 log4shell 취약점에 대한 탐지까지 가능한 것으로 파악됐다.

해당 도구의 장점은 뛰어난 확장성을 가지고 있다는 점이다. Spring MVC, Struts 등 다양한 SW 개발 프레임워크와 Eclipse, IntelliJ, Android Studio 등의 통합개발 환경(IDE) 도구, Jenkins와 SonarQube와 같은 도구에서 활용이 가능하다.

시큐어 코딩 점검 도구는 개발 단계에서 시큐어 코딩을 적용하는데 많은 도움을 줄 수 있다. 그러나, 이러한 점검 도구도 프로그램에 한정적으로 등록된 공격 패턴과 오류 탐지 기능을 가지고 있기 때문에 웹쉘 공격에 대하여 완벽한 대응책이 될 수는 없다. 시큐어 코딩 적용뿐만 아니라 웹 서버 또는 웹 서비스에 대한 안전한 설정값을 적용하고 더 나아가 웹쉘 탐지 솔루션을 도입하는 등의 유기적이고 복합적인 대응책이 마련되어야 한다.

2) 사후 대응 관점에서의 전략

마지막으로 앞서 언급한 사전 대응 전략을 수립하였음에도 불구하고 공격자의 웹쉘 공격이 성공할 가능성을 배제할 수 없다. 따라서, 웹쉘 공격에 대비하여 주기적으로 웹 로그 모니터링, 서버 이상 행위 모니터링 등을 수행하는 등의 공격이 발생한 것을 파악하고 이에 따른 빠른 대응이 필요하다. 본 문서에서는 웹 서비스 로그에 대한 설명을 간략하게 해보도록 하겠다.

웹쉘 공격은 보통 웹을 통해 발생하기 때문에 웹 접근 로그(access.log)를 확인하는 것이 선행되어야 한다. 그 이유는 웹 접근 로그에는 초 단위로 웹 페이지에 접근한 기록이 남아 있어 비정상적인 접근을 확인할 수 있는 증거가 될 수 있다. 아래의 [그림 18]의 예시는 극단적으로 웹쉘을 통해 공격을 수행한 로그 기록이지만 이처럼 단 시간 내에 비정상적으로 임의의 웹 페이지에 대한 접근 기록이 존재한다면 웹쉘 공격으로 의심을 해봐야 한다. 그러나 대부분의 웹쉘 공격은 POST 메소드 방식으로 패킷을 전송하고 정상적인 페이지와 비슷한 파일명을 가지고 접근하기 때문에 웹 접근 로그를 통해 완전한 웹쉘 공격을 알아차리기는 매우 어려울 수 있다.

그렇다면 차선책으로 error.log를 분석해 보는 것도 웹쉘 공격을 탐지하고 대응하는 데 있어서 좋은 방안이 될 수 있다. error.log에는 웹 서비스가 구동되면서 발생하는 Syntax 에러와 같은 주요한 에러에 대한 기록이 저장되어 있으며, 아래의 [그림 19] 처럼 에러 메시지를 이용하여 웹쉘 파일을 찾는 데 도움이 될 수 있다.

위에서 설명한 로그 데이터가 완벽한 대응 방안으로는 활용될 수 없다. 웹쉘에 의해 추가적인 악성 프로그램이 설치될 수 있으므로 Windows event log, 웹 방화벽 로그, 구동 중인 프로세스 목록 등 다양한 부분을 유기적으로 살펴봐야 한다.

05. 마무리

지금까지 최근에 사용된 웹쉘에 대한 분석과 대응 방안에 대하여 살펴보았다. 웹쉘 공격은 오래전부터 사용되어 온 매우 기초적인 공격 방식이고 많은 대응 방법이 존재하지만 웹 프레임워크나 서비스, 플랫폼 등에서 지속적으로 발견되는 보안 취약점을 통해 공격에 이용되고 있다.

이에 따라, 앞으로도 매우 영향력 있는 공격 방식으로 웹쉘은 지속적으로 등장할 것이기 때문에 보안 취약점에 관심을 가지고 패치 관리, 소스코드 관리, 로그 모니터링 등 다양한 부분에서의 관리가 필요하다. 이와 같이 기본적인 보안 대책 사항들을 적용하면 웹쉘로 인한 피해를 최소화할 수 있을 것으로 생각된다.

06. 참고자료

1) CVE-2022-41040 and CVE-2022-41082 – zero-days in MS Exchange
https://securelist.com/cve-2022-41040-and-cve-2022-41082-zero-days-in-ms-exchange/108364/
2) Alfa TEaM Shell Github
https://github.com/PhenaxGod/Alfa-Shell
3) Ensiko: A Webshell With Ransomware Capabilities
https://www.trendmicro.com/en_us/research/20/g/ensiko--a-webshell-with-ransomware-capabilities.html
4) 취약한 Atlassian Confluence 서버를 대상으로 하는 공격 사례
https://asec.ahnlab.com/ko/36563/
5) DriftingCloud: Zero-Day Sophos Firewall Exploitation and an Insidious Breachhttps://www.volexity.com/blog/2022/06/15/driftingcloud-zero-day-sophos-firewall-exploitation-and-an-insidious-breach/
6) What are Web Shell Attacks? How to Prevent Web Shell Injection?
https://www.ssl2buy.com/cybersecurity/web-shell-attacks
7) Attackers Exploit New Zero-Day Vulnerabilities on Exchange Server
https://www.stellarinfo.com/blog/attackers-exploit-new-zero-day-vulnerabilities-on-exchange-server/
8) Detect and Prevent Web Shell Malware
https://media.defense.gov/2020/Jun/09/2002313081/-1/-1/0/CSI-DETECT-AND-PREVENT-WEB-SHELL-MALWARE-20200422.PDF