정보보안 업계에서 일을 하면서 정보보안업계는 다른 IT 업종과 참 많은 것이 다르다는 것을 알게 됐지만 그 중에서도 큰 차이점은 과도하게 “기술 지향적”이라는 점이다. 쉽게 말해 “정보보안전문가 == 해커” 이라는 등식이 당연하게 받아들여 진다는 것이다. 이런 잘못된 인식은 정보보안전문가를 목표로 하는 젊은이들이 리버스엔지니어링(악성코드분석), 웹 취약점 공격, 패킷 분석 등 특정 분야의 기술습득에만 몰두하게 되는 부작용을 낳고 있다.
만약 정보보안전문가들이 악성코드를 만들어 배포하고 해킹을 시도하는 해커만큼의 기술적 수준을 갖고 있어야 한다면 해킹을 방어하는 것은 거의 불가능할 것이다.
정보보안전문가는 해킹에 악용되는 취약점과 해당 취약점을 공격하는 악성 코드의 코드 하나하나가 아니라 해당 취약점을 내포하고 있는 SW나 System을 이해하는 것과 악성코드가 동작하는 개념, 그리고 해당 취약점을 공격하여 공격 대상 서버 혹은 시스템에서 해커가 얻는 것이 무엇이며 취약점 공격을 통해 얻은 것으로 무엇을 할 수 있는가를 찾아내는 능력을 키우는 것이 더 중요하다.
CVE로 명명되고 있는 취약점은 매우 다양하며 해커들에 의해 앞으로도 끊임없이 많이 발견될 것이고 해커들은 해당 취약점을 공격하는 악성코드를 생산해 낼 것이다. 그렇다면 과연 그러한 취약점을 일일히 하나도 빠짐없이 정보보안전문가들이 코드 하나 하나까지 분석하고 대응해야 하는 것일까? 그것은 정보보안전문가들에겐 너무도 비효율적이다 못해 잔인한 일이다. 그것은 악성코드 분석 전문가에게 맞기고 그들이 분석한 결과를 활용하는 것이 옳은 방향이다. 모두가 악성코드 분석 전문가가 될 필요는 없다.
이번 포스팅에서 다룰 내용은 바로 그런 관점에서 수많은 취약점을 이용해 해커가 하고자하는 행위인 운영체제 쉘 권한의 획득을 방어하기 위해 운영체제가 갖고 있는 Shell의 실행을 SecureOS를 통해 통제하는 것이 얼마나 효율적인 정보보안대책인지를 이야기하고자 한다.
Shell의 취약성
대부분의 운영체제는 Shell 이라고 하는 대화형 사용자 인터페이스를 제공한다. Unix와 linux는 bash(본어게인쉘)을 비롯해 sh, ksh, csh, tcsh 등 다양한 쉘(shell)을 지원한다. 그리고 Windows 운영체제의 경우에도 cmd.exe를 지원한다.(예전엔 하위 윈도 호환을 위해 command.com도 있었음)
그런데 이 쉘은 보안에 매우 취약하다. 그리고 이 취약성은 해커들에게는 다른 수많은 취약점의 공격을 통해 꼭 얻어내야 하는 성지와 같다. 운영체제 벤더인 IBM, HP, Oracle(과거의 Sun), RedHat 등은 이 취약성을 제거하는데는 관심이 없다. 그리고 앞으로도 제거에 앞장서지는 않을 것이다. 왜냐하면 Unix와 Linux의 근본 사상이 무너지는 결과도 초래할 수 있기 때문이다.
여기에서 이야기하는 쉘의 취약성은 쉘이 갖고 있는 버그(?)로 인한 기술적 취약성이 아닌 운영체제의 근본 개념에 의해 발현되는 근본적인 취약성이다. 즉 사용자가 매우 다양한 입력 경로를 통해 쉘에게 전달하는 명령을 쉘이 완벽하게 실행해주기 때문에 발생하는 취약성 아닌 취약성이다. 즉 사용자의 명령이 키보드 입력을 통해 전달되든 파일에 저장되어 파일명으로 전달이 되든, 다른 서비스 대몬으로부터 exec 함수를 통해 전달이 되든 가리지 않고 완벽하게 실행해주기 때문에 발생되는 취약성이다. 이 취약성은 어떤 기술적 취약성으로도 분류되지 않는 아무도 인정하지 않는 취약성이다. 왜냐하면 “쉘은 원래 그렇게 만들어졌기” 때문이다.
이 취약성은 tty 혹은 pts가 할당되거나 실제 사용자가 접속하여 키보드로 입력한 명령만을 실행하도록 하는 매우 단순한 통제 만으로도 매우 효과적인 통제를 수행할 수 있다. 그리고 이러한 방법은 기술적으로 비교적 간단하게 구현이 가능하다. 원래 쉘은 서버에 접속한 사용자에게서 명령을 입력받고 해당 명령의 파일을 찾아 실행시켜주는 역할을 수행하면 되기 때문이다. 하지만 쉘은 거기에서 그치지 않고 스크립트를 실행하거나 백그라운드로 배치 작업을 구동하는데도 이용되고 있기 때문에 현실적으로 적용이 어렵다. 이는 Windows 운영체제도 마찬가지다. 결국 제거할 수 없는 취약성인 셈이다.
해커들은 그 점을 악용한다. 해커들은 서버에 직접 Telnet, SSH, Terminal Service 등을 통해 접속하지 않고 어떤 방법으로든 쉘의 “제거할 수 없는 취약성”에 접근할 수 있는 다른 취약점만 찾으면 서버를 해커가 마음대로 조종할 수 있다는 것을 알고 있다. 아래의 경우도 같은 경우다.
이 화면은 이슈메이커스랩이라는 화이트해커그룹에서 악성코드를 분석한 결과다. 웹브라우저에서 구동되는 플래시의 취약점을 악용해 악성코드를 다운받게 하고 다운받은 악성코드가 Windows가 설치된 PC나 서버에 저장되어 있는 문서파일들을 Windows의 기본 쉘을 실행시켜 수집하기도 한다는 분석 결과다.
여기서 정보보안전문가라면 윈도의 쉘인 cmd.exe가 실행되었음을 포착하여야 한다. 수 많은 취약점과 악성코드들이 최종적으로 PC나 서버 내에서 무언가를 실행하기 위해 cmd.exe를 실행한다. 따라서 악성코드가 cmd.exe를 실행하는 것을 차단하면 해커의 해킹의지를 효과적으로 꺾을 수 있다. 해커가 희생자 컴퓨터에 콘솔이나 정상적인 원격접속을 하지 않고 희생자 컴퓨터에서 무언가 정보를 획득하거나 원하는 명령을 실행하기 위해서는 Windows의 경우 cmd.exe를, Unix나 Linux에서는 bash나 sh와 같은 쉘을 실행하여만 한다.
MS 오피스, 아래아한글, 어도비 PDF와 플래시, 그리고 GIF와 같은 이미지 등에서 발견되는 수많은 취약점들은 최종적으로 운영체제의 명령어나 쉘을 실행하기 위한 경유지 정도의 역할을 하는 경우가 대부분임을 알아야 한다.
따라서 PC나 서버의 운영체제에서 제공되는 쉘을 어떻게 통제하는가가 보안의 핵심 중 하나인데… 현실은 거의 통제되지 않고 있는것이 현실이다.
쉘(shell)의 통제 방안
쉘(shell)의 실행 통제는 사실 SecureOS가 없이는 불가능하다. 쉘의 실행 통제 필요성은 정보보안전문가라면 한번쯤은 필요성을 느껴보았겠지만 쉘의 실행을 통제할 수 있는 보호대책의 구현이 SecureOS로 가능하다는 것 조차도 많이 알려지지 않다.
관련 포스트 보러가기 : Windows ASP 웹쉘 분석 및 차단 구현
쉘의 실행을 통제함으로써 구현 가능한 대표적인 보호대책이 바로 “웹쉘(webshell)의 실행 차단”이다. 일반적으로 웹서버의 수 많은 취약점을 통해 서버에 웹쉘을 업로드하거나 운영체제의 명령어를 실행할 수 있는 인젝션(Injection) 취약점을 악용하여 운영체제의 쉘을 실행하게 되는데 취약점에 관계없이 웹서버 프로세스를 통한 명령어의 실행을 원천적으로 차단할 수 있게 된다. (관련 포스트 보러가기 : Windows ASP 웹쉘 분석 및 차단 구현, Unix/Linux 웹쉘 차단 구현)
웹쉘 이외에도 Windows의 쉘인 cmd.exe와 Unix/Linux의 쉘인 sh, ksh, csh 등은 실행 감사로그를 수집하여 분석하고 정상적인 주체에 의해서만 실행이 허용되어야 한다. 만약 여러 이유로 인해 실행을 통제하기 어렵다면 웹서버 대몬, DB 프로세스 등 잠재적 취약성이 있는 애플리케이션에서의 쉘 접근은 최소한 차단하도록 보호대책을 수립해야 한다. 이러한 보호 대책은 SecureOS 인 RedCastle을 통해 구현할 수 있다.
SecureOS인 RedCastle을 통해 운영체제의 쉘에 대한 실행을 통제하게 되면 쉘의 실행을 목적으로 다양한 취약점을 찾고 찾은 취약점을 공격하는 악성코드를 작성하여 침투해도 악성코드가 쉘을 실행하지 못함으로써 해커가 원하는 목적을 이루지 못하게 된다. 따라서 보안담당자는 쉘을 실행시킬 수 있는 수많은 취약점에 일일히 대응하지 않아도 되며 정기적인 보안 패치의 적용하면 된다. Zero-Day 취약점에 효과적으로 대응할 수 있는 것이다.
운영체제의 쉘에 대한 접근 통제를 수행할 수 있는 유일한 보안 솔루션은 RedCastle SecureOS다.
사족
정보보안업계가 기술적 취약점 하나 하나에 너무 집착하게 됨으로써 흔히 정보보호담당자를 뽑을 때 해킹대회 입상자나 리버스엔지니어링과 같은 기술을 요구하는 구인광고를 보게된다. 사실 리버싱기술을 갖고 있거나 해킹대회에 입상할 정도의 실력을 가진 화이트해커라면 특정분야의 기술적 수준은 높겠지만 관리적보안이나 해당 분야가 아닌 다른 분야의 실력은 예상만큼 높지 않을 가능성이 더 많다.
오히려 운영체제와 운영체제에서 구동되는 다양한 시스템소프트웨어, 예를 들면 클러스터나 백업소프트웨어, 데이터베이스, 배치스케줄러와 미들웨어(웹로직, 제우스, 웹스피어 등)등의 역할과 특징을 이해하고 있으면서 네트워크나 데스크탑 컴퓨터의 특성을 종합적으로 이해하고 있으면서 보안의 기술적, 관리적 체계를 이해하고 있는 사람이 더 적임자라고 말하고 싶다.
기관이나 기업의 정보보호담당자는 특정 분야의 해킹기술 보다는 다양한 IT 분야의 다양한 경험과 관리적 보안에 대한 노하우를 고르게 갖고 있는 사람이 더 적합하다 하겠다. 제 아무리 보안을 전공하고 박사학위를 받았더라도 AIX, HPUX, CISCO Switch와 같은 하드웨어 인프라와 Oracle, Sybase, Weblogic, tuxedo, JEUS 등의 DB와 Java 기반 미들웨어, 게다가 NetBackup, Control-M, HACMP, MC-ServiceGuard 등의 시스템 소프트웨어를 모르는 보안 담당자가 시스템 엔지니어들을 통제하면서 제대로된 기술적 보호대책을 수립할 수 있겠는가?
십수년 전부터 구축되는 정보시스템은 네트워크, 운영체제, 웹, 미들웨어 등 다양한 솔루션들이 융합되어 하나의 시스템을 이룬다. 수십개의 솔루션이 유기적으로 연동되고 융합되어 정보를 수집하고 가공하고 저장하며 분석하고 표현해준다. 그 과정에서 발생할 수 있는 정보의 유출과 파괴는 악성코드 분석기술, 패킷 분석기술만으로는 예방하고 차단할 수 없음이 자명하다.
여러 금융기관과 대기업의 정보보호조직이 시스템과 네트워크 운용조직에 이리치이고 저리치이면서 제대로 된 기술적 보호대책을 구현하지 못하고 물리적 출입통제에 사운을 건 듯 매달리는 이유다.
정보보호전문가를 꿈꾸는 젊은이라면 “C, Java, Web은 물론 서버 및 데스크탑 운영체제, 데이터베이스, 네트워크 프로토콜, PKI 등 기반 기술은 물론 다양한 시스템소프트웨어까지 닥치는 대로” 공부해야 한다. 정보보호전문가는 IT분야 종사자의 최초의 직업이 아니라 최후의 직업이 되어야 제대로 일할 수 있다.