[Case Study] 시스템 관리자의 고민: 웹쉘에 대한 방어

대부분의 기업들은 정보보호 자산을 지켜내기 위해 방화벽(Firewall), 침입탐지시스템(IDS), 침입차단시스템(IPS)등의 네트워크 보안 장비를 운영하고 있다. 더불어 최근에는 웹 기반 공격의 영향으로 인해 웹방화벽(Web Application Firewall, WAP)까지 이용하는 경우도 증가하고 있다. 그러나, 공격자는 지능적인 공격 기법의 도입을 통해 이러한 차단, 탐지 방식을 우회하는 방법을 끊임없이 만들어내고 있다

네트워크 접근제어 체계가 정상적으로 운영되는 단계라면, 공격자는 80, 443 포트 정도를 이용한 제한적 공격만이 가능하게 된다. 이때 공격자가 적극적으로 이용하는 것이 웹 애플리케이션 취약점 공격 기법이다. 즉, 공격자는 원격에서 시스템 명령어 조작을 위해 웹쉘이라는 애플리케이션을 이용해 공격을 수행하게 된다. 만약 웹 사이트를 구성하는 웹 애플리케이션에 취약점이 존재할 경우, 기본의 탐지, 차단 방어체계는 일시에 무너진다. 또한 공격자가 원격에서 웹 브라우저만을 가지고도 시스템의 명령어를 조작하여, XDMCP, RDP 프로토콜을 원격에서 수신할 수 있으므로 관리자와 동등한 환경에서 공격을 효과적으로 수행한다.

 

[그림 1] 침해사고 분석 시 발견된 웹쉘

 

[그림 1]은 침해사고 분석 시 발견된 웹쉘이다. 이 그림에서 확인할 수 있듯이, 공격자는 웹 브라우저를 통해 공격 대상 시스템의 디렉터리 목록의 열람할 수 있다. 더불어 편집이나 시스템 명령어의 원격 조정이 가능이다. 물론 이러한 웹쉘은 Wscript.shell, Scripting.FileSystemObject, CreateTextFile 등의 패턴을 토대로 IDS, IPS 또는 WAF에서 탐지하여 차단할 수 있는 방법이 존재한다.

 

[그림 2] 웹쉘을 방어하기 위한 웹 방화벽의 정규표현식 구문

 

[그림 2]와 같이 실제 웹 방화벽에서 웹쉘의 드라이브 레터를 방어하기 위한 정규표현식(Regular Expression) 구문을 볼 수 있다. 이러한 패턴이 공격자의 공격을 효과적으로 방어하게 하는 역할을 담당한다. 또한 보안담당자는 이러한 패턴을 항상 최신으로 구현하여, 새로운 공격의 변화에 적절히 대응해야 한다.

 

이러한 공격의 효과적 차단 정책에도 불구하고, 공격자는 많은 우회기법을 동원하고 있다. 그 중에서 많이 사용되는 것이 각종 암호화 방식이나 난독화 기법(Obfuscation)이다. 

 

[그림 3] 정상적으로 동작하는 웹쉘

 

[그림 3]은 알 수 없는 의미같이 보이지만, 사실은 정상적으로 동작하는 악성공격을 위한 웹쉘 구문의 일부이다. 이러한 공격 구문을 네트워크 단위에서 탐지하고 차단하는 것은 대단히 어려운 일임에 틀림없다. 또한, 최근의 공격자는 아래와 같은 방법을 이용하기도 한다.

 

[그림 4] 보안 장비를 우회하기 위해 최소 단위의 공격 구문을 사용한 예

 

[그림 4]의 구문은 IDS에서 탐지된 실제 네트워크 보안 장비 탐지 데이터 원본(Raw Data)이다. 공격자는 공격 탐지 구문 전체에서 1,000Byte 정도만이 네트워크 보안장비의 로그에 남는다는 사실을 알고, 최초 1,000byte내에 확실하게 공격구문이라고 판단되는 부분을 남겨놓지 않고 있다. 실제로 위 내용은 웹쉘이며, 공격 구문 전체는 1,000byte 밖의 범위에 존재한다. 따라서, 전문가가 네트워크 장비의 로그를 보더라도 이것이 웹쉘인지의 여부를 판단하기는 쉽지 않다. 위의 경우에는 공격자가 고의적으로 앞의 1,000byte 정도를 글자 폰트 크기와 색깔 등의 설정에 소비하고 있는 화면이다.

또한, 공격자는 웹쉘 업로드 시 네트워크 장비에서의 탐지를 회피하기 위해 각종 인코딩(Encoding) 방법을 통해 난독화된 웹쉘 업로드 방식을 구현하고 있다. 독자들의 이해를 돕기 위해 안랩의 자동화 분석 시스템이 아닌 일반적인 분석 도구인 Malzilla를 통해 해당 내용을 설명해 보고자 한다.

 

[그림 5] 인코딩 방법을 이용한 웹쉘 공격을 분석한 화면

 

위 그림에서는 웹쉘이 base64 decode 형태로 실제 침해사고 분석 대상 시스템에 업로드 된 상태이다. 이 스크립트를 디코딩(Decoding)한 결과는 [그림 6]과 같다. 

[그림 6] 웹쉘 공격 스크립트를 디코딩(Decoding)한 화면

 

스크립트 분석 결과, 해당 페이지는 인증창이 존재하고(Password 123456을 입력해야 웹쉘에 접근가능) 시스템 포트 스캐너와 SQL 명령어 수행 등 거의 모든 기능을 수행한다는 것을 알 수 있다. 따라서 알 수 없었던 암호화 웹쉘은 결국 시스템에서 아래와 같이 동작한다.
 

[그림 7] 중국어 페이지로 구성된 웹쉘

 

역시나 예상했던 바와 같이, 중국어 페이지로 구성된 웹쉘이 나타났다. [그림 7] 화면에서 확인 할 수 있는 바와 같이, 시스템 관리자가 할 수 있는 거의 모든 시스템 운영 업무를 웹 브라우저를 통해 수행할 수 있다.

이때, 시스템에 남게 되는 access_log 형태는 아래와 같다.

 

 

따라서 해당 웹쉘에 접근한 이용자가 access_log 파일에서 확인될 경우, 해당 IP 접속자가 공격자 임에 틀림없다. 이러한 방법을 통해 파악되는 IP를 토대로 공격자의 공격이 성공했던 원인을 파악하는 것은 대단히 중요하다.

 

[그림 8] 난독화된 웹쉘을 디코딩(Decoding)한 결과

 

물론 [그림 8] 내역에서와 같이 난독화된 웹쉘을 디코딩(Decoding)해 보니, 또 하나의 암호화 구문이 웹쉘 안에 숨겨져 있는 경우도 있다. 최근의 웹쉘은 아래와 같은 취약점 유도 iframe을 마우스 클릭만으로 삽입하는 기능이 존재하기도 한다.

 

공격자는 마우스 클릭만으로도 시스템에 iframe을 삽입하여, 해당 사실을 모르는 일반 홈페이지 접속자는 꼼짝없이 악성코드에 의해 PC 시스템이 감염되거나, 봇넷(Botnet) 역할을 하기도 한다.

이러한 웹쉘의 위협으로부터 자유로울 수 있는 방법은 지속적인 IDS, IPS, Web Firewall 탐지 및 차단 패턴의 적용이라고 볼 수 있다. 그러나, 일반적인 네트워크 관리자가 이러한 공격 패턴을 파악하고 적용하는 것은 불가능에 가깝다.

따라서, 아래와 같이, 웹쉘 스캐너를 이용해 시스템을 주기적으로 점검하는 것이 바람직하다. 

[그림 9] KISA에서 배포하고 있는 웹쉘 스캐너인 휘슬(Whistl)

[그림 9]은 한국인터넷진흥원(KISA)에서 배포하는 휘슬(Whistl)이라는 웹쉘 스캐너이다. KISA에 소정의 신청양식과 함께 신청하며, 해당 도구를 이용할 수 있다.
 

[그림 10] 웹쉘 검색 도구인 Iscanner

또한, [그림 10]의 화면은 Iscanner 라는 검색 도구이며, 각종 패턴을 사용자 정의 또는 Default 규칙에 따라, 탐지해 내는 도구이다.

그러나, 웹쉘 패턴은 단 3분 정도만 차단에 실패해도 시스템에 심각한 피해를 주는 침해사고로 이어지는 만큼, 앞서 언급한 휘슬(Whistl)이나 Iscanner의 특성상 사후 감사 기능이라는 점은 침해사고를 효과적으로 방어하기는 힘들다는 것을 알 수 있다.

 

[그림 11] 안철수연구소에서 제공하는 쉘클린 관제서비스

안철수연구소에서는 관제서비스 중 쉘클린(ShellClean) 서비스를 제공하고 있다. 이러한 웹쉘을 실시간으로 탐지하고 차단하는데 효과적인 관제 서비스이다. 쉘클린’의 강점은 웹쉘 전용 솔루션이므로 공격을 방어하기 위한 별도 설정이 필요 없고, 웹쉘 감염 여부 검사 기능은 물론 실시간 탐지 기능도 제공한다. 따라서 단시간에 이뤄지는 공격 및 흔적 제거, 재공격을 위한 추가 웹쉘 설치에 신속하고 효과적으로 대응할 수 있다. <Ahn>