웹쉘에 대해서 조금만 파악한다면 방화벽에서 차단이 가능하다

 공격자는 몇가지 원칙을 갖고있다.

1. 윈도우 서버에 주로 삽입한다.
2. 방문자 규모가 큰 곳을 노린다.
3. 한번 성공한 곳은 왠만해선 포기하지 않는다.
4. 주말 낮시간에도 일한다. 공무원은 아닌 것 같다.
5. 국내 호스팅 서버를 경유지를 이용한다.

아웃고잉 정책도 필수다. any 정책으로 운용중이라면 당장 정책을 수립해야 한다.

아웃고잉포트감시를 통해 특정포트가 중국쪽으로 리슨되어 있다면 당장 차단해야 한다.

와이어샤크(Wireshark)를 이용한 패킷분석도 가끔 해봐야 한다. 좋은 결과를 얻을수 있었다.

Webshell은 악의적인 해커에 의해 설치되는 Web Scribt의 일종으로 자신이 관리중인 Web Server에 Webshell이 설치되어 있다면 해당 Web Server는 이미 해커에 의해 해킹이 완료 되었음을 뜻하며 또한 발견된 Web Server는 해커에게 발견되어 Webshell이 업로드 될 정도의 치명적인 보안 결함이 있는 것으로 판단하여야 한다.

이러한 취약점은 대부분 SQL Injection, 또는 upload file에 대한 관리 소흘로 인해 주로 발생되는 것으로 알려져 있지만 위 2개의 문제점 만으로 발생하는 것으로 판단하기는 힘들며, 일단 Web Server에 설치된 이후에는 해커가 원하는 거의 모든 작업을 Web Server에서 수행할 수 있다고 생각해야 한다. Web code 열람, Web에 접근하는 사용자들을 대상으로 하는 악성코드배포 ( 여기서 악성코드는 해커가 원하는 모든 것들이 가능) 및 삽입, 파일 업로드, 데이터베이스 자료 유출 등 다양한 공격과 응용이 가능하여 Webshell을 통한 공격은 피해의 정도가 다른 Web Hacking과 비교가 되지 않을 정도이다.

구버전의 Webshell들은 최근 보안 이슈였던 WAF 일명 웹방화벽으로 해결이 되지만 근래의 Webshell들은 이러한 방화벽의 os명령어 또는 system 명령어 필터링 기능을 피해가기 위해 다양한 변종 명령어를 이용 변형하여 서버에 전송가능하게 하는 Webshell들도 일부 생겨나기 시작했다. (대부분 중국산) 모든 부분의 보안이 그러하듯 WebShell 역시 창과 방패의 싸움의 시작일 뿐이다.

웹쉘은 공격자가 악의적인 목적을 가지고 만든 프로그램으로, 주로 주로 SSS(Server Side Script)언어 (ASP, PHP, JSP등)를 사용하여 제작함. 웹쉘이 완성되면, 취약점이 존재하는 서버에 업로드시킵니다. 일단, 공격자가 만든 웹쉘이 성공적으로 서버에 업로드가 된다면, 공격자는 자신이 서버에서 실행시키고자 하는 명령어를 전송하여, 서버에서 실행이 되게 함. 즉, 공격자는 해당 서버의 모든 제어권을 장악하고, 정보탈취, 변조, 악성스크립트 삽입등 각종 악성행위를 함. 웹쉘공격은 HTTP서비스를 통하여 통신을 하기 때문에 탐지가 매우 어려우며, 제작이 비교적 쉽고 서버제어 및 관리가 용이하기 때문에 흔히 사용되는 공격방법 이다.

웹쉘 공격을 예방하기 위해서는

1. 시큐어 코딩
2. 취약점 패치
3. 키워드/명령어 필터링
4. 업로드 파일의 확장자 및 실행권한 제한

Webshell은 기본적으로 소스코드의 일종이다. 일반적인 안티 바이러스 유틸이나 웹쉘 전문 툴이라 하여 100% 차단하거나 탐지해내는 것은 불가능하다. 라는 것이 일반적인 상식이다. 이것은 웹방화벽의 기능이 아무리 좋아도 웹프로그래머의 실수 또는 미숙으로 인해 발생하는 소스코드 자체가 갖는 보안상의 취약점에 대해서는 전혀 대비 할 수 없는 것과 같은 이유이다. 가장 근본적인 부분(코드)이 해결되지 않는 이상 이러한 문제점에서 100% 자유롭다고 이야기 할 수 있는 웹서버 또는 보안장비는 없다.

telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기,실행(w,x)을 갖고 있는 디렉토리를 찾아야 한다.

ASP의 Eval, Execute메소드 등은 원격에 있는 공격자로부터 웹쉘 실행코드를 전달 받아 실행 하는데 많이 이용되고 있 다. 이 같은 Eval, Execute 코드는 정상적인 스크립트 파일에도 삽입이 가능해 웹쉘 탐지가 더욱 어려워 지고 있다.

-참고 –

• Eval 메소드 : string(문자열 저장)을 자바스크립트 코드로 변환해 주는 메소드
• Execute 메소드 : 질의어, SQL 문장, 프로시저 등을 실행시켜 주는 메소드

파일 업로드가 불필요한 게시판의 경우는 업로드의 기능을 완전히 제거하고, 필요한 경우에는 파일의 확장자를 체크한다. 업로드를 제한하는 asp, chi, php, isp 등의 확장자를 막는 방법으로 구현하는 것보다 허용하는 확장자 즉, txt, hwp, doc, pdf 등의 업로드 가능한 파일 확장자만 올릴 수 있도록 체크하는 것이 바람직하다. 그 이유는 특정 확장자만 막는 경우에는 우회해서 올릴 수 있는 방법들이 존재하기 때문이다. 또한, Php, Asp, jSp 등의 대소문자 혼용 및 .txt.asp 등의 2중 확장자의 형태도 필터링 해야한다.

웹서버의 파일 업로드 전용 폴더를 만들고 전용 폴더의 스크립트 파일 실행을 제한하여 해당 폴더내에 있는 파일이 실행되지 않도록 해야 한다. 윈도우 서버의 경우 [설정] – [제어판] – [관리도구] – [인터넷서비스관리자] 에서 마우스 오른쪽 버튼을 클릭하여 [등 록정보] – [디렉토리]를 선택해 실행권한을 ‘없음’으로 설정한다.

리눅스의 경우 httpd.conf와 같은 웹서버 설정 파일에서 변경한다.

웹쉘 공격은 파일 업로드 취약점 뿐만 아니라 SQL Injection을 이용해서도 가능 하므로 DB쿼리문에 삽입하여 사용하는 모든 경우에 이러한 필터를 적용하여 단 한 개의 페이지에서라도 SQL Injection의 허점이 존재하지 않도록 주의해야 한다.

리눅스의 경우에는 암호화된 웹쉘을 검사하기가 까다로울 수 있는데, 이럴 경우에는 한국정보보호진흥원에서 제공하는 휘슬(Whistl: Web Hacking Inspection Security Tool)7)을 이용하면 쉽게탐지할 수 있다. 휘슬은 인터넷침해사고대응센터(http://www.krcert.or.kr) 웹 사이트에서 휘슬 사용 신청서를 다운로드받아 작성하여 제출하면 제공받을 수 있다.