SecureOS의 역사와 국산 SecureOS 제품의 비교

Posted by taeho Tae-Ho
2015.07.30 17:41 정보보호

2000년을 전후하여 처음 접하게 된 보안 솔루션이 있었습니다. 


첫 직장에 입사 후 2년간의 개발 업무를 거쳐 Ingres RDBMS 기술지원 2년여... 그리고 시스템 통합관리 소프트웨어인 CA Unicenter 제품군과 BMC Patrol 제품을 거쳐 공부하게 된 보안솔루션이 바로 SecureOS 솔루션인 CA eTrust Access Control 입니다.


eTrust Access Control은 운영체제에 동적 커널 모듈 (DLKM : Dynamic Loadable Kernel Module)로 구현된 Secure OS 즉 보안 운영체제입니다. 운영체제라고 하여 Solaris, Linux와 같은 통~ 운영체제는 아니고 상용 운영체제에 DLKM으로 개발된 일종의 드라이버를 로드하여 보안 기능을 강화하도록 만들어진소프트웨어 모듈입니다.


그리고 몇년 뒤 회사를 이직할 때 선택한 회사가 바로 국산 SecureOS 제품인 RedCastle을 개발하는 레드게이트였습니다. 이때 부터 서버보안만 한우물을 파게 되었는데 10여년이 다된 지금까지도 SecureOS(서버보안)를 중심으로 대부분의 업무를 수행하고 있습니다. 다만 SecureOS의 제품변화 또는 기술적 발전 속도는 매우 더딥니다. 일부 영업맨들과 보안 전문가들은 몇년 전부터 SecureOS(서버보안) 시장이 포화상태라 할 정도로 시장의 성장도 느리고 기술의 변화도 느립니다. 


하지만 SecureOS는 서버 운영체제에 로그인한 사용자 혹은 서버 운영체제 위에서 실행되는 서비스에 대한 통제를 수행하는 보안SW이기에 서버 운영체제를 잘 아는 엔지니어나 개발자가 아니면 이해하기 어려운 솔루션입니다. 


SecureOS는 예전에 발생한 농협사태와 카드사 개인정보 유출과 같이 서버 엔지니어나 서버에 직접 로그인하여 작업을 수행하다 발생하는 보안사고를 예방하고 차단할 수 있는 유일한 보안 솔루션입니다.

SecureOS(보안 운영체제:서버보안)의 역사

SecureOS 역사의 시작은 Unix 서버 운영체제가 미국 국방망에 도입되어 사용되기 시작한 1970년대 초 즈음 부터~라고 보는 것이 옳습니다. 때문에 딱히 언제다...라고 못박기는 쉽지 않습니다. (대략 1970년대 라고 알려져 있음) 초기 SecureOS는 메인프레임 및 유닉스 운영체제의 소스코드내에 강화된 보안기능을 지원하는 코드를 추가하면서 즉, 운영체제 자체의 보안성을 강화하는 형태로 발전하였습니다. 이렇게 자체적으로 보안성이 높은 운영체제를 Trusted OS 라고 부르기도 합니다. 


하지만 운영체제 마다 각기 다른 형태로 보안성을 강화하다 보니 기능적인 측면이나 관리적인 측면에서 일관된 보안 정책의 구현이나 통합관리가 어려웠기 때문에 당시 시장에서 확산되기 시작한 Unix 운영체제에 공통적으로 사용될 수 있는 DLKM 형태의 SecureOS가 연구되기 시작하였습니다.


그리고 확실하게 알려진 바는 없지만 1990년에 설립된 이스라엘의 Memco(멤코)라는 보안기업에 기술이 이전(추측)되었고 1990년대 중반에 최초의 DLKM 방식의 SecureOS인 SeOS가 개발되어 판매되기 시작하였습니다. 이후 이스라엘 Memco사의 SeOS를 플라티늄테크놀로지가 인수하였고 다시 다시 미국의 거대 소프트웨어기업인 CA(컴퓨터어소시에이츠)에 인수되는 우여곡절을 거칩니다. 


우리나라에 최초로 SecureOS가 도입되기 시작한 것은 1990년대 후반입니다. SeOS가 매우 완성도가 높고 경쟁상대가 없었기에 거의 독점적으로 국내의 금융관련공기업과 일부 공공기관 그리고 대기업 위주로 알음알음 시장을 장악해 들어왔습니다. 당시에는 네트워크 기반의 방화벽 조차도 제대로 갖추지 못한 기관들이 많았기 때문에 매우 단순한 형태의 서버 해킹이 자주 발생하였고 SeOS를 통해 방어하도록 정책을 구현했던 사례들이 많습니다.저도 이때 처음 SeOS를 접하게 되었습니다.


하지만 초기에는 Unix 운영체제 자체의 안정성이 낮았던 데다 SecureOS의 커널모듈을 로드하게 되어 안정성을 더욱 떨어뜨리는 요인이 되었고 수 많은 장애를 유발하기도 하였습니다. 때문에 지금까지도 SecureOS는 "장애를 많이 일으키는 보안 솔루션"으로 인식되고 있기도 합니다. 

국산 보안운영체제(SecureOS)의 개발

그리고 국내에서도 1990년 즈음부터 연구가 시작되어 2000년을 전후하여 ETRI와 KISA를 거친 일부 연구원들에 의해 국산 SecureOS가 개발되어 시장에 뛰어듭니다. 국산 SecureOS는 모두 DLKM 방식입니다. 이 DLKM의 핵심기능은 바로 참조모니터 기능입니다. 이 참조모니터를 얼마나 안정적으로 빠르게 동작하도록 만드느냐가 핵심 기술입니다. 그리고 운영체제의 다양한 자원에 대한 액세스를 안정적으로 빠르고 가볍게 가로채는 참조모니터의 개발은 결코 쉽지 않습니다. 때문에 2015년 현재 안정적인 SecureOS의 참조모니터 개발 기술을 보유하고 있는 보안 기업은 중소기업 두세곳에 지나지 않습니다. 그리고 늘어날 가능성도 거의 없습니다.


현재 국산 보안운영체제를 개발하여 시장에 공급하고 있는 기업은 딱~ 세 곳 입니다. 가히 삼국시대라 할 수 있습니다.


가장 먼저 SecureOS를 개발한 곳은 바로 Secuve(시큐브) 입니다. 제품명은 TOS 구요. 아마 Trusted-OS의 약자인 듯 싶습니다. 시큐브는 현재 코스닥에 상장되어 있습니다. Secuve TOS의 가장 큰 특징은 PKI 인증서 기반의 접근통제를 수행한다는 점입니다. 인증서에 단순한 인증정보만 담는 것이 아니라 인증서를 발급받은 사용자의 추가적인 권한에 대한 정보를 담아 서버에 접속할 때, 명령어나 파일에 접근할 때 접근통제를 수행하도록 정책을 구현할 수 있습니다. 하지만 인증서를 사용하는 방식은 실제 서버 운영자들에게는 매우 불편한 방식이어서 인증서를 사용하지 않고도 보안 정책을 수립할 수 있게 되어 있지만 TOS의 가장 핵심적인 가치를 배제하는 것이고 접근 통제 방식 자체를 변경하게 되면서 조금은 어정쩡한 상태의 제품이 되었습니다. 


그리고 시큐브는 사업 영역을 점차 응용보안 쪽으로 이동시키고 있는 듯 합니다. 이는 시큐브가 여러 고객사에 제안하는 내용을 보면 알 수 있는데 아무래도 서버보안(SecureOS) 시장의 성장이 정체되어 있다고 생각하기 때문이 아닌가 싶습니다. TOS 자체의 기능 보강이나 확장이 그다지 눈에 띄지 않습니다. 그리고 개선해야할 것으로 보이는 기능도 개선되지 않고 있습니다. 대신 시큐브는 계정관리(Identity Management), 로그 통합관리 솔루션 그리고 커널 수준이 아닌 응용 수준에서 명령어의 실행을 통제하는 방향으로 제품을 개발하고 있는 것으로 보입니다. 


시큐브의 TOS는 주로 공공기관을 주 고객으로 삼고 있습니다. 그리고 최근 몇년간 민수 시장을 적극 공략하고 있지만 공공시장에서만큼의 파급력을 보이지는 못하고 있습니다. 


두번째로 출시된 SecureOS는 티에스온넷의 레드아울(RedOwl) 입니다. 하지만 티에스온넷은 하우리에 인수되었고 점차 시장에서 그 위상을 잃고 있는 분위기 입니다. 과거 시큐브레인이라는 회사의 하이자드라는 SecureOS가 안철수연구소에 인수되었다가 시장에서 사라진 사례를 떠올리게 하고 있습니다. 현재는 주로 국방과 철도 등 일부 시장에서 사용하고 있는 것으로 보입니다. 


그리고 초창기와는 달리 제품의 형상도 크게 변화가 없고 군쪽을 제외하면 최근에는 대형 프로젝트에도 제안하지 않는 경우가 많습니다.


세번째로 출시된 SecueOS는 바로 레드비씨의 RedCastle입니다. 최초의 제조사는 RedGate라는 회사입니다. 제 블로그에서 주로 다루는 SecureOS이기도 합니다. 레드비씨는 PKI 및 전자문서 보안 기업인 비씨큐어와 RedCastle 제조사인 레드게이트가 합병되어 탄생한 보안솔루션 기업입니다. 그리고 코스닥에 상장되어 있기도 합니다.


RedCastle은 다른 두 SecureOS에 비해 가볍고 실제 서버 운영체제 내의 자원에 대한 접근통제 정책을 수립하기에 매우 적합하게 개발되어 있습니다. eTrust Access Control (SeOS)의 주요 기능을 벤치마킹하여 파일접근통제 기능을 개발하였고 직접 개발이 어려운 서버방화벽 기능을 과감하게 운영체제에서 제공하는 패킷필터링 모듈을 연동하여 지원하는 등 운영체제의 성능과 안정성에 최대한 영향을 적게 주도록 최적화 시켰습니다. 때문에 1금융권의 계정계와 정보계, 인터넷뱅킹 시스템 등은 물론 공인인증기관의 주요 핵심 공인인증 업무 서버에서도 안정적으로 도입되어 사용중에 있다고 할 수 있습니다.


게다가 레드비씨는 최근의 시장 요구를 가장 먼저 반영하고 있습니다. OTP, ARS, PKI 등의 2차 인증 인프라를 접목하여 서버에 접속할 때 2차 인증을 수행하고 서버에 로그인한 사용자가 누구인지 실제 자연인을 식별하여 명령어 실행 및 파일에 대한 감사로그를 기록하도록 하는 기능을 업계 최초로 적용하였으며 이미 서버에 로그인한 사용자라 하더라도 특정 명령어를 실행할 때는 한번 더 2차 인증을 받거나 ARS를 통해 상급자에게 실시간으로 승인을 받아야만 실행을 할 수 있도록 하는 명령서 사용 승인 기능과 시스템의 주요 작업 시 작업 신청/승인/정책스케줄링을 수행하는 명령어 통제 시스템으로의 확장도 구현하였습니다.


SecureOS(서버보안)의 주요 벤더인 3개 사 중에서 SecureOS의 본연의 역할에 가장 충실하고 체계적이고 보수적으로 기능을 확장해 나가는 벤더가 바로 레드비씨 입니다. 저 또한 그러한 레드비씨의 SecureOS 개발 철학이 마음에 들었고 같은 목표를 지향하기에 10년 이라는 시간을 우여곡절이 많았음에도 레드비씨에 투자할 수 있었다고 하겠습니다.

Secuve TOS .vs. RedCastle

글로 두 제품을 비교하는 것은 큰 의미가 없습니다. 많은 고객사와 SI 기업에서 비교자료를 요구하지만 그것은 그저 "두 제품을 비교했다"라는 요식행위를 갖추기 위한 것일 뿐입니다.


두 제품을 제대로 비교하자면 많은 테스트와 필드 경험이 필요합니다. 전 총 3제품을 테스트해봤습니다. 외산인 eTrust Access Control (현재 이름은 Control Minder : 콘트롤 마인더)과 RedCastle 그리고 Secuve TOS 입니다.


SecureOS의 아키텍쳐 측면에서는 RedCastle에게 가장 큰 점수를 주고 싶습니다. Security Category와 Security Level로 구성되는 보안속성(Security Label)을 사용자와 파일에게 부여하고 프로세스에게는 사용자의 보안속성이 상속되며 부여된 보안속성을 비교하여 Switch User 통제, Kill 통제, 프로세스 생성통제, 파일접근통제를 수행하는 강제적접근통제 기능은 처음 보았을 때 무릎을 치며 감탄할 수 밖에 없었습니다. eTrust Access Control 도 B1 시큐리티 기능에서 해당 기능을 제공하지만 기술적인 문제와 기능상의 문제로 실제 적용하기에는 부적합했는데 RedCastle에서는 파일접근통제를 제외한 나머지 부분에는 훌륭하게 적용이 가능했기 때문입니다. TOS의 경우 제가 테스트 했던 버전에는 인증서 기반이 아니기 때문인지 보안속성과 관련된 메뉴를 찾아볼 수 없었습니다. 


게다가 일부 Secuve TOS와 RedCastle을 모두 사용해본 고객사에서는 접근통제가 가능한 파일의 개수에 제한이 있다는 정보도 얻을 수 있었습니다. RedCastle에 파일접근통제 기능을 개발할 때 Wildcard인 * 을 사용할 수 있게 개발해달라고 요청하여 접근을 통제할 파일을 /usr/bin/* 혹은 /web/html/*.html 과 같이 하나의 규칙으로 파일의 개수와 관계없이 접근 통제를 할 수 있도록 하였습니다. 그래야만 보안 정책을 단순화할 수 있고 실제 보안정책의 수립이 가능하기 때문입니다. (사실 이렇게 지원해도 불편한 경우가 생기긴 합니다.) 하지만 Secuve TOS는 와일드카드를 지원하지 않기 때문에 모든 보호대상 파일을 리스트업하거나 디렉토리명을 기준으로 정책을 수립해야 합니다. 게다가 개수의 제한도 발생할 수 밖에 없습니다.


와일드카드인 * 는 RedCastle과 eTrust Access Control 만이 지원하는 기능입니다.

 

기능 면에서는 SecureOS의 조상이자 원조라 할 수 있는 eTrust Access Control이 가장 다양한 기능을 제공합니다. 앞에서 설명한 와일드카드의 경우 eTrust Access Control은 * 기호 이외에도 ? (한글자 패턴매칭)를 지원합니다. 그 외에도 글로벌 기업 답게 매우 다양한 기능을 제공하는데 어떤 고객사도 모든 기능을 다 사용하지는 않습니다. 전체의 50%도 사용하지 못합니다. 다음이 RedCastle이고 그 다음이 Secuve TOS 입니다. TOS의 경우 제가 테스트하는 서버에 전체 기능이 모두 설치되지 않았는지는 모르겠지만 제품의 스펙으로 제시하는 기능의 일부를 찾을 수 없는 경우가 많았습니다. 고객마다 다른 제품을 설치하는 것인지 모르겠습니다.


마지막 비교 포인트는 SecureOS에서 가장 중요한 지표인 안정성입니다.


안정성의 경우에도 경험에 의해 주관적으로 판단할 수 밖에 없는데 RedCastle이 단연 최고의 안정성을 보여줍니다. 어떤 인터넷 쇼핑몰 고객사의 경우 RedCastle을 초기에 도입했다가 유지보수 비용 문제로 인해 타 제품으로 교체하였습니다. 하지만 채 3년이 되지 않아 다시 RedCastle을 설치하기로 한 사례가 있습니다. 그 당시 이유는 바로 "기능'과 "안정성" 이었습니다. 

RedCastle은 한 고객사에서 운영하는 수백대의 서버에 단시간에 설치하는 사례가 흔합니다. 하지만 장애가 발생하는 경우는 많아야 한-두대에 지나지 않습니다. 그 한-두 대도 CPU 사용율이 높다던가 특별한 설정이나 SW가 설치되어 있어 발생하는 경우가 대부분입니다. 제품의 자체 버그로 인해 장애가 발생하는 경우는 훨씬 빈도가 낮아집니다.

그 외에도 해킹으로 인한 보안사고가 발생한 고객사에서 타사 제품을 통해 해킹을 차단하지 못해 RedCastle로 교체 도입하거나 기능상의 제약으로 인해 제품을 변경하는 경우도 경험할 수 있었습니다.


하지만 어쨌든 비교 대상인 세 SecureOS는 일정 수준의 안정성을 확보한 제품입니다. 그랬기에 시장에서 살아남을 수 있었고 나름대로 점유율을 확보할 수 있는 것입니다. 다만 차이가 크지는 않지만 분명 안정성과 기능면에서는 차이가 있다는 것을 말씀드리고 싶습니다. 특히 SecureOS를 제대로 활용하여 서버의 보안성을 높이고 싶은 기업이나 공공기관이라면 다른 제품보다는 RedCastle을 도입할 것을 권하고 싶습니다.



신고
이 댓글을 비밀 댓글로
    • 2016.04.20 13:56
    비밀댓글입니다
    • 아...레드아울을 사용하셨군요.. 저도 접해보고 싶은 secureos인데.. ^^
      인적이 드문 블로그인데 댓글 감사합니다..

사물 인터넷 보안 취약성과 보호대책

Posted by taeho Tae-Ho
2015.07.13 18:12 정보보호

사물인터넷(Internet Of Things)의 보안 취약성


얼마 전 신용카드 결제 단말기의 보안 강화를 위해 KTC(한국기계전기전자시험연구원)에서 추진하던 시도가 여러가지 이유로 인해 무산되는 일이 있었습니다. 그 과정에서 블로그를 통해 친분이 있는 VAN사에서 근무하시는 지후대디님과 신용카드 결제 단말기의 보안강화에 대한 KTC의 요구에 대응하는 기술의 구현을 위해 몇 차례 미팅을 가진적이 있었습니다. 그리고 지후대디님이 근무하시는 VAN사는 결제 단말기의 보안 강화에 대해 매우 적극적으로 대응하고 계셨고 SecureOS의 임베디드리눅스의 포팅에 상당히 긍정적이었습니다.


하지만 결론적으로는 결제단말기의 인증시험일정의 촉박함과 구현 방식에 대한 여러 VAN사와 카드사 그리고 KTC의 의견차이로 인해 이번에는 인증요건에서 빠지고 말았습니다.


신용카드 단말기는 세상에 가장 많은 IOT 기기 중 하나입니다. 요즘엔 롯데리아나 맥도널드 홈서비스는 물론 동네 치킨집 배달하시는 분들까지도 신용카드 결제 단말기를 들고 다니죠. 만약 신용카드 단말기가 대량으로 해킹될 경우 카드 복제와 혼란은 아마도 상상을 초월할 수도 있습니다.


그리고 신용카드 결제 단말기의 보안강화를 위한 KTC의 시도가 무산된지 얼마 지나지 않은 현재...결제 단말기가 해킹되어 신용카드 정보가 유출되고 신용카드가 복제되어 무단으로 사용되고 있는 것으로 보이는 사건이 발생했고 수사중이라는 뉴스가 올라오고 있습니다. (연합뉴스 기사 보러 가기) 아직은 수사중이라 정확한 사고 경위는 알 수 없지만 신용카드 결제 단말기에서 카드 정보가 유출된 것으로 보인다고 합니다.



또 하나의 가장 대표적인 사물인터넷 디바이스는 집집마다 하나씩은 갖고 있는 인터넷 공유기입니다. 저희 집에는 두개가 있네요. 통신사에서 제공하는 공유기와 제가 별도로 구입하여 사용하고 있는 IPTIME의 공유기입니다.


그리고 최근에는 이 공유기 하위에 원격에서 제어가 가능한 가스밸브잠금 장치, 홈 CCTV, IPTV 셋탑박스, 인터넷전화기 등등 보안에 취약한 사물인터넷 디바이스가 이미 많이 사용되고 있습니다. 이러한 인터넷 공유기 하위에 연결되어 있는 집집마다 설치되어 있는 "인터넷 공유기"를 해커가 장악하면 모두 제어가 가능합니다. 영화에 나오 듯 악당이 전세계의 IPTV 시청자에게 자신이 송출하는 협박 영상을 강제로 시청하게 하는 것이 불가능한 것이 아닌 세상이지요.


그래선지 모 통신사가 선도적으로 기가 홈 와이파이 공유기에 SecureOS를 적용하여 보안성을 강화하려는 시도를 하고 있습니다.


사물인터넷의 주요 운영체제인 임베디드리눅스의 보안 취약성

사물 인터넷 디바이스는 운영체제를 사용하는 경우도 있고 그렇지 않은 경우도 있습니다. 운영체제를 사용하지 않는 경우는 불가능하지만 운영체제를 사용하는 경우는 주로 임베디드 리눅스가 사용됩니다. 일반적인 리눅스 운영체제를 256M 이하의 디바이스에서도 구동될 수 있도록 슬림화한 운영체제가 임베디드 리눅스 입니다. CPU도 인텔계열이 아닌 ARM이나 퀄컴, 브로드콤 등의 AP에서도 구동될 수 있도록 포팅이 되어 있습니다.


이러한 임베디드 리눅스는 근간이 리눅스인 이유로 여러 취약점들을 갖고 있습니다.



이러한 보안 취약점들이 더 위험한 이유는 바로 사물인터넷 디바이스들이 네트워크 구조 상 보안 시스템이 존재하지 않는 네트워크에 위치하기 때문입니다. 사물인터넷의 대표적인 기기들인 신용카드 결제 단말기나 인터넷 공유기 등은 악의적 목적을 가진 해커가 물리적으로 기기에 접근하는 것을 제한하거나 기술적으로 네트워크 수준에서 접근 통제를 하고 있지 않은 환경에서 됩니다. 즉 무방비로 해커에게 노출되어 있는 것이죠. 그래서 앞의 그림에서 나열되어 있는 취약성을 해커들은 손쉽게 공격할 수 있습니다.


사물 인터넷 보안 강화를 위한 SecureOS

공유기가 설치된 각 가정마다 방화벽이나 침입차단 시스템을 설치할 수는 없습니다. 때문에 사물인터넷 디바이스 자체의 보안성을 강화하는 것이 가장 좋은 보호대책이라고 할 수 있습니다. 그런 측면에서 임베디드리눅스에서 구동될 수 있는 SecureOS는 악성코드의 감염이나 파일의 변조를 차단하고 사물 인터넷 디바이스에 침투하려는 해커의 시도를 차단하는데 가장 효과적이라 할 수 있습니다.



그래선지 요즘은 사물 인터넷 보안 강화를 위해 RedCastle SecureOS를 임베디드 리눅스에 포팅할 수 있는지를 타진하는 문의가 자주 오고 있습니다.



신고
이 댓글을 비밀 댓글로
  1. 신용카드 단말기도 초기에 필요성이 대두되었다면 리눅스 단말이 대세이다보니 어쩌면 취약성 보호를 위해 채택되었을지도 모르겠습니다
    • KT와 진행하는 기가홈공유기와 IOT게이트웨이로의 포팅도 단말기 제조업체와의 협상이 관건인 것 같습니다. 공유기하나에 5~6만원 정도에 납품하는 것 같기에 원가 상승 요인으로 작용하기에 단말기 제조업체들의 반응이 자체개발을 하고 싶어 하는 것 같습니다. 하지만 쉽지 않다는 걸 알기에 고민...또 고민하고 있는 것 같구요.
      납품단가 후려치기의 폐해가 느껴집니다. ^^

카스퍼스키(Kaspersky Lab)를 공격한 두쿠2.0 (Duqu 2.0)

Posted by taeho Tae-Ho
2015.06.16 10:47 정보보호

요 몇일 사이에 두쿠라는 악성코드가 보안업계에 초미의 관심사로 등장했다. 하지만 이 두쿠(Duqu) 2.0 이라 명명된 악성코드는 그 실체가 아직도 밝혀지지 않고 있다. 


일반적인 악성코드와는 다른 두쿠(Duqu 2.0)


일반적으로 악성코드는 PC나 서버에 파일이라는 "흔적"을 남긴다. 


악성코드 분석 전문가인 리버스엔지니어링 전문가들은 이 파일을 가져다가 분석하고 실행시켜보면서 어떤 레지스트리를 수정하고 어떤 파일을 생성하며 어떤 취약점을 공격하는지를 분석한다. 이 작업은 전문가들에게도 매우 고되고 힘든 작업이다. (쉽게....노가다..다.. 사명감이나 재미를 느끼지 못한다면 그 일을 하지 못한다고 말하고 싶다.)


그런데 이 두쿠2.0은 파일을 남기지 않는다고 한다. 게다가 어떠한 시스템의 레지스트리도 건드리지 않는다고 카스퍼스키는 밝혔다. 즉 이상을 느낀 사람이 컴퓨터를 리부팅하면 그 컴퓨터는 깨끗한 상태가 되기 때문에 어떤 공격을 당했는지 어떤 파일이 유출되었는지 전혀 알 수 없다고 한다. 기술적으로 불가능하지는 않겠지만 여지껏 볼 수 없었던 새로운 개념의 악성코드다.



때문에 카스퍼스키도 매우 난감해하고 있는 것으로 보인다. 아래는 카스퍼스키 CEO의 인터뷰 내용 중 일부다.


유진 카스퍼스키 CEO는 “공격자가 누구인지 모르겠지만 우리 회사에 대해 많은 공부를 하고 자료를 조사한 게 틀림없어 보입니다. 아마 지금도 감시를 하고 있을 겁니다. 특히 저희의 백신 기술이나 분석 자료를 위주로요. 또 저희의 특별한 멀웨어 감지 노하우도 찾고 있겠죠”라고 자신의 의견을 밝혔다.


카스퍼스키는 두쿠 2.0의 기술적인 내용들도 함께 공개했다. 그에 따르면 두쿠 2.0은 세 가지 제로데이 취약점을 공략하고 있는데 이 중 하나는 지난 화요일 MS가 패치를 한 것으로 정식 명칭은 CVE-2015-2360이다. 나머지 두 개는 CVE-2014-6324와 아직 밝혀지지 않은 취약점이라고 한다. “아직까지 이 세 번째 버그는 미스터리입니다. 공격자가 피해자의 브라우저 히스토리와 인박스를 죄다 지웠거든요. 그래서 최초 공격이 어떻게 이루어졌는지 알 수가 없습니다.”


“예상하기로는 굉장히 고급화되고 맞춤화된 스피어피싱 공격이었을 것 같습니다. 거기에는 악성 웹사이트 링크가 있었던 것으로 보고요. 아마 CVE-2014-4148 정도가 제일 가까운 버그가 아닐까 합니다.” 이는 카스퍼스키의 최고보안분석가인 커트 봄가트너(Kurt Baumgartner)의 설명이다.


남겨져 있는 두쿠2.0의 파일이 없기 때문에 침투 경로를 파악하는 것이 매우 힘들다는 내용이 요점이다.


게다가 이 두쿠2.0이 과거 SCADA망을 공격했던 스턱스넷과도 연관이 있을 것이라 예상하고 있다.


카스퍼스키 랩의 세계 리서치 및 분석 팀의 책임자인 코스틴 라이우(Costin Raiu)는 얼마 전 개인 트위터를 통해 두쿠 2.0의 모듈 중 하나를 화면으로 출력한 스크린샷 이미지를 공개했다. “이 파일이름과 경로를 어디서 본적이 있다면 우리에게 알려달라”는 트윗과 함께 말이다.


하지만 아직 아무도 제대로 된 정보를 카스퍼스키에 제보한 것 같지는 않다. 다만 여기에 등장하는 파일의 이름 중에 HMI가 있어 산업통제 시스템이나 SCADA와 관련이 있는 것으로 추측하고 있다. HMI는 인간 기기 인터페이스(human-machine interface)의 준말로 생산산업 내에서는 널리 쓰이는 표현 중 하나다.


Copyrighted 2015. UBM-Tech. 117153:0515BC


위에서 등장하는 파일명은 아마도 메모리상에 존재하던 두쿠2.0을 분석할 때 나온 파일명으로 보인다. 실제 파일로는 존재하지 않기 때문이다. HMI라는 용어가 제조산업 특히 발전사에서 사용하는 용어임에는 틀림없다. HMI라는 단어가 씌었다고 해서 꼭 SCADA망과 같은 제어망을 목표로 했던 스턱스넷과 관련이 있다고 장담할 수는 없겠지만 충분한 개연성을 갖고 있을 가능성도 배제해서는 안될 것이다.


대응 방안

사실 근본적인 대응방안은 MS의 운영체제와 그 운영체제 위에서 구동되는 애플리케이션을 사용하지 않는 것이 가장 좋은 대응방안일 것이다. 하지만 현실적으로 이는 불가능한 대응방안이다. 


내가 생각하는 특별한 대응방안은 "없다"이다.


특별한 대응방안이 없다는 것은 역으로 현재까지 알려진 일반적인 대응 방안을 충실히 이해하는 것이 가장 확실한 대응방안이 될 수 있다고 본다. 이번 두쿠 2.0의 감염경로를 분석한 자료를 보면 MS-Word 파일과 같은 파일을 인터넷에서 다운받아서 최초 감염이 일어난 것으로 예상하고 있는 것을 알 수 있다. 물론 이 두쿠2.0이 제로데이 취약성을 공격하고 있긴 하지만 "외부에서 침투한 파일"에서 최초 공격이 일어났다는 점은 이전의 피싱이나 파밍과 다를 바 없다.


따라서 외부에서 다운로드 받은 의심스러운 파일, 의심스러운 웹사이트 방문, 의심스러운 이메일 등을 식별할 수 있는 안목을 개개인이 키울 수 있도록 지속적인 교육이 필요하다고 할 수 있다.


그와 더불어 망분리, 성능 좋고 안정적인 보안 솔루션의 도입과 체계적인 운용 등이 어우러질 때 보안사고는 획기적으로 줄어들 것이라는 점을 잊어서는 안된다. 그리고 아울러 "완벽한 보안은 없다"는 경각심을 갖고 상시 모니터링 체계를 유지하는 것도 중요하다.




신고
이 댓글을 비밀 댓글로

공유기 해킹을 통한 파밍의 대응 방법

Posted by taeho Tae-Ho
2015.04.19 00:02 정보보호

파밍 공격의 사례


언제부턴가 인터넷 공유기의 해킹이 파밍 공격을 위한 수단으로 악용되기 시작했습니다. 가장 대표적인 공유기 해킹 그리고 DNS 변조를 통한 파밍 사례는 아래의 사례처럼 정상적인 포털사이트와 금융기관 홈페이지에 접속하여도 가짜 포털 및 금융기관으로 접속 되도록 유도하는 경우입니다.





이 사례는 웹브라우저의 주소창 혹은 즐겨찾기 등 어떤 방법으로든 "http://www.naver.com"을 정상적으로 입력하고 접속하였음데도 가짜 웹사이트로 접속하도록 접속경로를 변조한 경우입니다. 금감원의 팝업창을 사칭하여 금융기관에서 발급한 보안카드 정보를 빼내기 위한 파밍공격 사례죠.


그렇다면 어떻게 이런 공격이 가능할까요... 이는 모든 네티즌이 인터넷을 사용하기 위해서 필수적으로 사용하는 DNS 라는 서비스의 취약성과 공유기의 취약성이 결합되어 매우 치명적인 취약성을 만들어 내기 때문입니다. 이 취약성을 이해하기 위해선 가정마다 보급되어 있는 인터넷공유기와 DNS서비스에 대해 알아야 합니다.


DNS 서비스에 대해서는 이 포스트에서 따로 설명드리진 않습니다. 대신 위키백과를 연결해 드립니다. 잘 모르시는 분들은 방문하여 차분히 읽어보시면 금새~이해가 되실 겁니다.


위키백과의 '도메인 네임 시스템'


인터넷 공유기와 DNS (Domain Name Service)

1995년을 전후하여 ADSL이 상용화 되면서 인터넷이 집집마다 보급되기 시작했습니다. 그리고 가정마다 인터넷을 사용하는 컴퓨터나 노트북 등이 두개 이상으로 늘어나게 되었고 인터넷 공유기는 날개 돋힌 듯 팔려나갔습니다. 그리하여 현재는 집집마다 최소 1개 이상의 공유기가 설치되어 있다고 해도 과언이 아닙니다. 


이렇게 집집마다 설치되어 있는 인터넷 공유기는 다음과 같이 가정의 인터넷 망을 구성하게 해줍니다.



공유기에는 집 밖에서 들어오는(통신사에서) 인터넷 선이 연결되는 포트(port)가 있습니다. 위의 공유기에서는 IPTIME의 공유기 사례인데 노란색 포트가 통신사에서 들어오는 인터넷 회선이 연결되는 포트입니다. 그리고 집 내부에 있는 PC나 노트북은 주황색 포트에 연결됩니다.


통신사에서 들어오는 인터넷 선이 연결되면 공유기는 통신사에서 공인IP를 받아옵니다. 이 공인IP는 이따금씩 변경이 되기 때문에 자동으로 공인IP를 받아오도록 공유기에 설정되어 있습니다. 공유기에 공인IP가 설정되면 그때부턴 전세계 어디서든 공유기에 설정된 공인IP만 알면 우리집의 공유기에 접속할 수 있다고 보면 됩니다. 그리고 이때 DNS 서버의 IP도 함께 받아 오도록 기본 설정되어 있습니다.


그리고 공유기에 연결되는 노트북이나 PC 또는 스마트폰은 공유기로 부터 사설IP를 자동으로 할당받는 것이 일반적입니다. 그리고 DNS 서버의 IP주소도 자동으로 공유기로 부터 받아오도록 기본 설정이 되어 있습니다.


공유기가 통신사로부터 받아오는 공인IP와 DNS 주소는 다음과 같이 확인할 수 있습니다. (공인IP는 보안상 공개하지 않습니다. 저도 해킹당하기는 싫거든요.. ^^)


[공유기가 통신사로부터 받아온 DNS 주소]


[노트북이 공유기로부터 받아온 노트북의 IP주소와 DNS 서버주소]


인터넷공유기와 DNS 서비스 취약점

위의 그림에서와 같이 공유기가 통신사로부터 DNS 서버 주소를 자동으로 부여받고 그렇게 부여받은 DNS 서버 주소를 하위의 PC나 노트북, 스마트폰에게 자동으로 부여하도록 설정한 경우에 파밍 취약점이 발생합니다.


즉 공유기를 해킹하여 공유기가 통신사로 부터 부여받은 정상적인 DNS 서버 주소를 "변조(바꿔치기)"할 수 있다면 하위의 PC와 노트북, 스마트폰 등이 정상적으로 http://www.naver.com 을 입력하여 네이버 포털에 접속하려 할 때 해커가 준비해둔 가짜 네이버 사이트로 접속하도록 진짜 네이버 사이트의 IP 주소가 아닌 가짜 네이버 사이트의 IP를 알려줘 사용자가 무방비 상태로 가짜 사이트로 접속을 유도하여 네이버의 ID와 비밀번호와 같은 개인정보를 탈취할 수 있게 됩니다.


즉 인터넷 공유기의 관리자 페이지에 불법적으로 접속할 수 있는 취약점과 DNS 서버 주소를 릴레이 하듯 전달하는 취약점이 만나 파밍이 가능하게 되는 것입니다.


대응 방법

먼저 취해야할 대응방법은 공유기의 접속 보안 설정 입니다.


대부분의 공유기는 처음 설치 시 접속 보안이 설정되어 있지 않습니다. 즉 공유기에 접속하여 관리자 설정을 할 때 ID와 비밀번호를 입력받는 기본적인 접속 보안 설정이 되어 있지 않아 공유기에 연결만 하면 누구든 공유기의 설정을 변경할 수 있습니다.


이 설정을 변경하여 공유기의 설정을 변경하기 위해서는 반드시 ID와 패스워드를 입력하여야만 설정을 변경할 수 있도록 보안 설정을 해야 합니다.


IPTIME 공유기의 보안 설정에 대해 잘 설명해둔 블로그를 소개해 드립니다. 다른 공유기도 대동소이한 방법으로 접속 보안 설정을 변경할 수 있습니다.


ipTIME 공유기 비밀번호 변경,설정 방법


두번째는 공유기의 보안 패치 입니다.


지속적인 공유기 해킹은 공유기 내부망이 아닌 공유기 외부망 즉 인터넷을 통해 공유기를 해킹할 수 있는 공유기 자체의 취약점들이 있기 때문에 발생합니다. 그래서 공유기 제조사들은 최근 공유기의 보안 패치를 내놓기 시작했습니다. 공유기의 보안 패치는 대부분 펌웨어 업데이트에 포함되어 나옵니다.


따라서 주기적으로 공유기의 펌웨어를 업데이트 하는 것이 바람직합니다.


그래도 DNS 주소 변조에 의한 파밍이 두려우시면 다음의 세번째 방법을 적용해보시기 바랍니다.


세번째는 바로 노트북(or PC or 스마트폰)의 DNS 서버 주소를 수동으로 지정해 주는 것입니다.


이 방법은 공유기가 해킹이 되고... 공유기가 공유기에 연결된 PC나 노트북 또는 스마트폰에게 알려줄 DNS 서버의 주소가 변조되어도 안전한 방법입니다. 이것은 PC나 노트북 또는 스마트폰이 DNS 서버의 주소를 공유기에게서 받는 것이 아니라 미리 PC, 노트북, 스마트폰에 수동으로 설정된 DNS 서버의 주소를 사용하는 방법입니다.


다음과 같이 윈도자체의 네트워크 설정에서 DNS 서버 주소를 수동으로 설정해 두는 방법입니다. 아래 화면은 KT의 DNS 서버 주소를 수동으로 설정한 화면입니다.



위 화면과 같이 DNS 서버를 자동으로 받기가 아닌 수동으로 설정하게 되면 윈도는 네트워크 초기화 시 공유기에게 윈도가 사용할 자체 IP 주소만 받아오고 DNS 서버 주소는 받아오지 않고 미리 설정된 주소를 사용하게 됩니다. 따라서 공유기의 DNS 서버 주소 변조가 발생해도 잘못된 사이트로 접속되는 사례는 발생하지 않습니다.



인터넷 공유기는 집안의 네트워크를 인터넷과 연결해주는 길목의 역할을 수행합니다. 그래서 매우 세밀한 관리가 필요한데 대부분의 인터넷 공유기는 방치되어 있는 수준으로 집집마다 설치되어 있습니다. 조금만 인터넷 공유기에 관심을 기울이면 공유기의 내부망 , 즉 집안의 네트워크에 평화가 깃들게 됩니다.





신고
이 댓글을 비밀 댓글로
  1. 공유기해킹을 통한 파밍의 대응방법
    을 모두 실천해서 집안 네트워크의 평화를
    추구해야겠습니다.^^
    유용한 정보 감사합니다.
    • 에스델님 집의 네트워크에 평화가 깃들기를~ ^^

주민등록번호 유출의 위험성 (통일된 개인 식별자 사용의 위험성)

Posted by taeho Tae-Ho
2015.03.23 11:19 정보보호

대한민국 국민의 주민번호는 우리나라에 인접한 중국에서 범죄자들 사이에서 현금으로 거래가 이루어질 만큼 해커들에게는 돈이 되는 정보입니다. 하지만 정작 피해자인 대한민국의 국민들은 심각하게 받아들이지 않고 있습니다. 자신의 개인정보가 범죄자들과 해커들 사이에서 사고 팔리는 상황임에도 그리 심각하게 받아들이지 않는 이유는 무엇일까요? 


주민등록 번호의 위험성


아마도 그 이유는 "주민등록 번호 하나로 뭘 하겠어?" 라는 안일한 생각이 머리속에 자리 잡고 있기 때문일 겁니다. 하지만 그런 생각은 큰 오산입니다. 데이터베이스에 대해 조금이라도 공부를 해본 사람이라면 데이터의 조인(Join)에 대해 배웠을 겁니다. 이 데이터의 Join을 이용하면 주민 번호 하나로 엄청난 정보들을 생산해 낼 수 있습니다.


다음 그림에서 그 예를 들어보이겠습니다.


어떤 사람 A가  K은행과 S보험사 그리고 1 쇼핑몰에 가입하며 아래 그림과 같이 몇개의 정보를 제공했습니다. 그리고 그 정보는 사이트마다 다릅니다.


하지만 A씨는 세 사이트에 공통적으로 "개인을 식별"하기 위해 요구하는 주민등록 번호를 입력했습니다. 해커가 이 세 사이트를 해킹하여 A의 개인정보를 빼냈다면 해커는 A의 주민번호를 기반으로 세 사이트에서 빼낸 정보에서 A의 완벽한 정보를 추출해낼 수 있습니다.


A의 이름과 K은행의 계좌 번호의 잔고는 물론 A의 핸드폰 번호와 가족관계 그리고 사는 곳의 주소까지 한방에 얻어낼 수 있습니다. 이 정보를 이용하면 얼마 전까지도 유행(?)했던 피싱이 가능합니다.


단계 1. A씨의 K은행 잔고를 확인하고 바로 송금할 수 있는 적당한 금액을 예상할 수 있습니다.


단계 2. A씨에게 1 쇼핑몰에서 얻어낸 전화번호로 전화를 겁니다.


단계 3. A씨에게 S 보험사에서 알아낸 자녀 정보를 이용해 자녀를 A씨가 살고 있는 동네에서 납치했다고 협박하고 단계 1에서 설정한 적당한 금액을 대포통장으로 보내지 않으면 자녀를 죽일수도 있다고 강하게 협박합니다.


위의 사례처럼 다수의 웹 사이트에서 빼낸 별 의미 없는 조각난 정보를 주민등록 번호를 통해 엮을 경우(이 엮는 과정을 데이터베이스에선 Join 이라고 부르며 데이터베이스에 대한 초보적인 지식만 있어도 사용할 수 있는 기술입니다.) 해커들이나 범죄자들에겐 매우 유용한 정보가 됩니다.


범죄자는 이미 유출된 매우 다양한 개인정보를 사들여 주민등록 번호를 통해 엮기(Join)만 하면 범죄에 악용할 수 있는 완벽한 개인정보DB를 구축할 수 있습니다. 궂이 새롭게 해킹할 필요가 없습니다. 이미 유출된 개인정보만 해도 충분할 것이기 때문입니다.


주민등록 번호의 위험성을 제대로 알리지 않는 정부


주민등록번호는 과거 간첩 색출을 쉽게 하기 위해 만든 구시대의 유물입니다. 그리고 그 본래의 목적을 다하고 이젠 거의 불필요한 상태입니다. 그럼에도 불구하고 정부는 국민의 통제와 관리에 편리하다는 이유로 주민등록번호의 폐지에 대해 매우 부정적일 뿐만 아니라 그 위험성에 대해서도 국민에게 제대로 알리지 않고 있습니다. 게다가 금융기관, 통신사는 물론 보험사와 여러 공기업과 사기업들이 단지 편의성 때문에 주민등록번호를 남용하는 것을 방관하여 개인정보유출과 보안사고를 방치하고 있습니다. 그러면서 매일 국민들에겐 백신 설치 타령하고 있고 기업들에겐 보안 강화 타령을 하고 있지요. 정작 정부에서 해야 할 일은 하지 않으면서 말입니다.


하지만 이미 유출된 개인정보는 어쩔 수 없다 하더라도 지금의 어린이들과 학생들이 미래에 겪을지도 모를 매우 위험한 범죄의 위협으로 부터 안전을 지킬 수 있는 가장 효율적인 방법은 전 국민에게 공통적으로 적용되고 기업들에 의해 활용될 수 있는 매우 위험한 "개인식별번호"를 만들지 않고 기업들과 공공기관이 함께 사용하지 않는 것입니다.


당연히 지금 현재도 무분별하게 사용되고 있는 주민등록번호의 폐지와 IPIN의 폐지도 긍정적으로 검토해야 한다고 생각됩니다.


연관포스트 : 개인정보의 범위와 무분별한 사용실태

신고
이 댓글을 비밀 댓글로
  1. 주민번호 노출이 너무 쉽게 이루어지는 경우가 많져. 며칠전에는 택배를 시켰는데, 사용자의 주민번호가 그대로 노출되어 배달이 되었다는 기사를 본 적이 있는데, 인식개선과 함께 제도적인 측면에서도 대책이 필요할 것같아요. 잘 보고 갑니다 ~
  2. 뭐... 실명 다 밝히고 봉사활동에서 만나는 사람에게도 강간당하는 세상인데 이런것쯤이야 예삿일이죠... 너무 세상이 각박해져가는 것 같습니다.
    • 맞아요..세상 참 각박하죠..
      너무 자기 이익만을 챙기려 하기 때문일거에요..
  3. 이미 유출된 개인정보만으로도 충분하다니~
    완전 충격입니다.
    주민등록번호 유출의 위험성에 대해
    더 많은 사람들이 정확히 알게 되길 바랍니다.
    • 안전불감증이 문제죠... 나만 아니면 된다는 이기심도 문제구요...
  4. 대비책으로 정부가 예전에 내 놓은 안이 또 다른 체계의 주민번호라 경악을 했던일이 기억납니다
    • 네..아이핀을 말씀하시는거 같네요.. 아이핀이 한동안 언급되더니..요즘엔 마이핀이라는 것도 나오더라구요.. 하여간 대한민국은 주민등록번호에 중독되어 있는 것 같습니다..
      아이핀이나 마이핀은 주민등록번호를 끊으면서 생긴 금단현상의 산물이 아닐까 생각됩니다. ^^

아이핀 해킹으로 75만건의 아이핀 부정 발급 사고

Posted by taeho Tae-Ho
2015.03.06 14:11 정보보호

주민등록번호의 대체제로 정부와 KISA에서 제시한 아이핀... 하지만 그 아이핀 마저 아이핀 관리 시스템 취약성으로 인해 75만건이 일시에 부정 발급 되는 보안 사고가 발생했다. 이로써 주민등록 번호와 크게 다를 바 없는 단순한 "일련번호와 같은 숫자"로 개인을 식별하려는 그 어떤 시스템도 보안 취약점만 발견되면 언제든 무력화 될 수 있다는 사실이 입증된 사건이라고 할 수 있다.


해킹에 의한 대량의 아이핀 부정 발급 사건 (2015년 2월)


2015년 2월 28일에서 3월 2일 사이에 발생한 이번 해킹 사건은  지금까지의 아이핀 부정 발급이 주로 개인정보 도용에 의한 것인 것과는 달리 공공 아이핀 시스템의 해킹을 통한 아이핀 대량 부정 발급이라는 점에서 아이핀 시스템 자체의 취약성이 매우 심각할 수도 있다는 것을 의미한다.



그리고 이번 해킹으로 부정 발급된 75만 건의 아이핀은 주로 게임사이트 등에서 이미 사용된 것으로 확인이 되었다고 한다. 


이렇게 부정 발급된 아이핀은 게임 사이트에서 아이디 탈취 등에 악용될 수 있기 때문에 아이디를 탈취하여 게임 아이템을 팔고 대포 통장으로 송금 받는 등의 피해가 발생했을 가능성이 높다. 그 외에도 매우 치명적인 사고의 주범으로 탈취된 아이핀이 악용될 수 있다는 점에서 매우 심각한 사태가 아닐 수 없다.


대한민국의 인증 강박증

우리나라의 인증 강박증은 세계적으로 유명하다. 모든 인터넷 서비스, 예를 들면 게시판에 댓글을 달 때 조차 실명 인증을 강요하는 보안이 철저한(?) 우리나라에서 개인정보 유출사고가 빈번하게 발생하고 그로 인해 심각한 피해가 발생하는 이유는 아이러니하게도 실명 인증(신원확인)에 대한 강박에서 비롯된다. 인증을 강화하는데 그 결과로 개인정보가 보호되는 것이 아니라 개인정보 유출 사고가 증가하는 역설적인 현상이 발생하는 것이다.


우리나라의 모든 공공기관과 기업에서는 고객과 국민 개인의 신원 확인에 이상하리 만치 집착을 보인다. 누가 누구 인지를 식별하고 본인인증을 받아야만 한다는 강박에 사로잡혀 있는 것이다. 그래서 공공기관과 기업은 과거 1968년 부터 간첩색출 등을 주 목적으로 만들어진 "주민등록번호"라는 전 국민에게 부여된 일련번호를 개인 식별과 인증에 사용하기 시작했다. 그리고 그때부터 인증강박증이 시작되었다. 주민번호에 의한 실명 확인을 하지 않는 시스템은 안전하지 않다는 불안감에 휩싸이는 것이다.


공공기관과 기업은 고객과 국민들에게 서비스를 제공하는 시스템을 만들면서 주민등록번호를 이용해 누워서 떡먹기 수준의 개발이 무척 간단한 개인 식별 및 인증 시스템을 구축하기 시작했다. 해외 처럼 매우 다양하고 복잡한 수단을 이용해 개인을 식별해야 하는 시스템을 구축하지 않고 Unique(고유한)한 주민등록번호를 이용하니 비용도 줄이고 시스템 개발도 쉽게 할 수 있었다. 한마디로 거저 먹었다는 표현이 적합할 것이다. 이렇게 편리하게 개인을 식별할 수 있다 보니 공공기관과 기업은 주민등록번호에 중독되었다 해도 될만큼 인증에 대한 강박증이 생겨버렸다.


하지만 정보 기술 환경이 좋아지면서 문제가 발생하기 시작한 것이다. 범죄자나 해커가 수 많은 개인정보 중 하나일 뿐인주민등록 번호만 획득하면 범죄의 타겟을 손쉽게 특정할 수 있고 여러 곳에서 빼낸 다양한 개인정보를 주민번호를 키(Key)로 하여 조합하여 완벽한 개인정보를 얻을 수 있게 된 것이다.


해커들에게 그야말로 대한민국 국민의 주민등록번호는 개인정보를 줄줄이 얻을 수 있는 개인정보 노다지의 시발점인 셈이고 그 시발점을 국가가 만들어 놓은 것이다.


아이핀 부정 발급에 악용된 취약점(파라미터 변조 취약점)

이번 아이핀 75만건 부정 발급에 이용된 공공 아이핀 시스템의 취약점은 "파라미터 변조 취약점"이다. 웹 서비스로 구성된 모든 애플리케이션은 기본적으로 파라미터 변조 공격에 노출되게 마련이다.


파라미터 변조 취약점은 클라이언트 서버 방식 혹은 웹 서비스와 같이 브라우저와 웹 서버처럼 분리된 환경에서 정보를 주고받거나 하나의 시스템 내에서 실행되더라도 여러 개의 프로세스가 서로 정보를 주고 받으며 동작하는 경우에 발생할 수 있는 매우 기본적인 취약점이다.


이번 사고의 경우 해커는 아이핀의 발급에 필요한 사전 사용자 인증 과정을 수행하는 웹 페이지에서 다음 단계인 발급 단계로 진행될 때 전달되는 정보(파라미터)를 변조하여 부정 발급을 받은 것이다.


이와 관련한 기술문서가 한국인터넷 진흥원의 인터넷침해대응센터에 공개되어 있다. (보러 가기)



신고
이 댓글을 비밀 댓글로
  1. 이번 아이핀 사건은 좀 충격이더라구요. 그렇게 걱정할 것 없다고 했던 아이핀, 사용하기도 불편했음에도 보안 때문에 사용을 했는데, 이런일이 생기니 좀 그렇네요 ^^;
    • 보안을 강화하겠다는 강박관념이 부른 사고라고 생각됩니다. (흔히 인증강박 이라고 하죠.) 보안은 개인들 스스로의 책임이라는 인식을 갖게 하고 스스로 책임을 질 수 있도록 잘 교육하는 것이 가장 효과적인 보안이죠.

개인정보보호법의 비밀번호 일방향 암호화 및 패스워드 관리 솔루션

Posted by taeho Tae-Ho
2014.12.04 18:17 정보보호

인터넷의 사용이 일반화 되면서 전 국민이 평균적으로 수 십 개의 웹 사이트에 가입되어 있고 그 숫자 만큼의 계정과 비밀번호를 갖고 있습니다. 그리고 웹서버, DB서버 등 수 십에서 수 백 대의 서버를 관리하는 IT 기업의 운영자들은 웹사이트의 계정 이외에도 서버 운영체제에 존재하는 여러 계정들에 대한 비밀번호도 관리해야 합니다. 개인 사용자들의 계정과 비밀번호와는 달리 서버 운영체제의 계정은 유출될 경우 보안 관점에서 매우 치명적인 문제가 발생할 수 있기 때문에 특별하게 관리되어야 합니다.


패스워드의 일방향 암호화에 사용되는 Hash 함수


개인정보보호법에서는 웹 사이트에서 사용되는 비밀번호는 물론 서버의 운영체제 관리자 계정, DB 관리자 계정, 애플리케이션 관리자 계정 등 주요 시스템 관리자 계정의 비밀번호가 유출되는 최악의 상황에서도 기밀성을 유지하도록 하기 위해 "일방향 암호화"를 해야 한다고 명시하고 있습니다.


개인정보의 안전성 확보조치 기준 (행정안전부고시 제2011-43호, 2011.9.30 제정)


제7조(개인정보의 암호화) ① 영 제21조 및 영 제30조제1항제3호에 따라 암호화하여야 하는 개인정보는 고유식별정보, 비밀번호 및 바이오정보를 말한다.

② 개인정보처리자는 제1항에 따른 개인정보를 정보통신망을 통하여 송·수신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다.

③ 개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 단 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다.

④ 개인정보처리자는 인터넷 구간 및 인터넷 구간과 내부망의 중간 지점(DMZ : Demilitarized Zone)에 고유식별정보를 저장하는 경우에는 이를 암호화하여야 한다.

(개인정보의 안전성 확보 조치 기준 고시 해설서)


일반적으로 패스워드(비밀번호) 이외의 데이터를 암호화를 할 때는 암호화에 사용되는 키(Key)가 필요합니다. 암호화를 할 때는 평문(읽을 수 있는 문서)을 암호 시스템에 키(Key)와 함께 입력하면 암호화 된 암호문이 출력됩니다. 그리고 반대로 암호문을 키와 함께 복호화(해독)시스템에 입력하면 평문이 출력 됩니다.


이것이 일반적인 암호시스템의 암호화와 복호화 입니다.


그런데 사용자 계정의 비밀번호의 암호화에 사용되는 일방향 암호시스템은 복호화(해독)시스템이 존재하지 않습니다. 이론적으로 복호화가 불가능한 암호 알고리즘을 사용하는 암호화 시스템입니다. 따라서 일방향 암호화 시스템에 의해 암호화된 비밀번호가 유출되어도 안전이 보장됩니다. 이러한 암호시스템에서 사용되는 암호화 알고리즘을 해쉬(Hash)함수라고 부르며 MD-5, SHA-1, SHA-256 등 여러 알고리즘이 공개되어 있습니다.



비밀번호의 암호화에 사용되는 알고리즘인 해쉬함수에 대해 위키피디아에서는 다음과 같이 정의하고 있습니다.


해시 함수(hash function)는 임의의 길이의 데이터를 고정된 길이의 데이터로 매핑하는 알고리즘이다. 해시 함수에 의해 얻어지는 값은 해시 값, 해시 코드, 체크섬 또는 해시 등으로 불린다. 해시 함수는 결정론적으로 작동해야 하며, 따라서 두 해시 값이 다르다면 그 해시값에 대한 원래 데이터도 달라야 한다. (역은 성립하지 않는다) 해시 함수의 질은 입력 영역에서의 해시 충돌 확률로 결정되는데, 해시 충돌의 확률이 높을수록 서로 다른 데이터를 구별하기 어려워지고 검색하는 비용이 증가하게 된다.


해쉬함수중에는 암호학적 해쉬함수(Cryptographic Hash Function)와 비암호학적 해쉬함수로 구분되곤 한다.


암호학적 해쉬함수의 종류로는 MD5, SHA계열 해쉬함수가 있으며 비암호학적 해쉬함수로는 CRC32등이 있다.


암호학적 해쉬함수는 역상(pre-image), 제2역상(2nd preimage), 충돌쌍(collision)에 대하여 안전성을 가져야 하며 인증에 이용된다 . 암호학적 해쉬함수는 임의의 길이를 입력 받기는 하지만 MD Strength Padding할 때 길이정보가 입력되므로 최대 길이에 대한 제한이 있다. 예를 들어 패딩시 하위 8비트에 길이정보가 입력 되는 경우에는 해쉬가능한 최대 길이는 0xFF가 되어 255바이트가 된다.(실제 길이정보는 패딩방식에 따라 다를 수 있다)


이 해쉬함수를 사용하는 대표적인 암호시스템은 Unix/Linux 운영체제의 계정에 대한 비밀번호를 예로 들 수 있습니다. Unix/Linux 시스템에는 root, oracle 등 다양한 계정들이 존재하게 되는데 이 계정들의 비밀번호를 Hash 함수를 써서 생성하고 관리합니다.


예를 들어 다음과 같이 oracle 계정(운영체제계정임)의 비밀번호를 oracle1! 로 변경합니다.

-bash-4.1$ id

uid=105(oracle) gid=10(staff)

-bash-4.1$ 

-bash-4.1$ passwd 

Enter existing login password:                       <-- 원래 비밀번호 입력

New Password:                                            <-- 변경할 비밀번호인 oracle1!

Re-enter new Password:                               <-- 변경할 비밀번호 한번더 입력 oracle1!

passwd: password successfully changed for oracle      <--- 변경되었음.

-bash-4.1$ 

-bash-4.1$ 


위와 같이 비밀번호를 변경하면 oracle1! 라는 비밀번호가 hash 함수에 의해 암호화 되어 /etc/shadow 파일에 다음과 같이 저장됩니다.

rctest3:$5$sr.Ua47p$C7JoY71vCoZW6BxcQFuZYA7T1THWn06U0KHvimHe.a/:16363::::::8016

oracle:$5$LWKPAHLI$/276CYHrCCxJ9fGMhF6k1HyuHvdKBDem23.HLJ9LXu5:16408::::::


위에 굵게 표시된 부분이 oracle1! 라는 비밀번호가 hash 함수에 의해 암호화된 암호문 입니다. 암호화 된 문장만으로는 암호화되기 이전의 평문을 알아내는 것은 현재의 암호학으로는 불가능합니다. 그래서 "일방향" 암호화라 부르는 것입니다. 때문에 암호화된 문자열이 유출되어도 비밀번호인 oracle1! 의 비밀이 지켜지는 것이지요. (하지만 다른 서버(운영체제 버전이 동일한)의 shadow 파일에 동일 암호문이 있다면 그 계정의 비밀번호도 oracle1! 라는 맹점이 존재하긴 합니다.)


그래서 개인정보보호법에서는 모든 비밀번호는 "일방향 암호화"하도록 의무화하도록 명시되어 있고 실제로는 서버마다 비밀번호를 다르게 설정하라고 권고하고 있는 것입니다. 비밀번호가 암호화된 데이터베이스나 서버의 shadow 파일이 유출되더라도 비밀번호를 복호화하지 못하도록 하기 위해서죠.


그런데 많은 보안솔루션들이 이를 위반하고 있습니다. 대표적인 제품들이 SAC라 부르는 제품들입니다. 그중에서도 서버에 로그인을 자동으로 해주는 기능을 사용할 경우 SAC의 관리서버에 서버의 root, administrator, oracle, jeus 등 매우 치명적인 문제를 일으킬 수 있는 계정의 비밀번호를 복호화가 가능한 SEED 등의 암호기법으로 저장하고 있습니다.

물론 키를 알아야만 복호화가 가능하겠지만 그 키 조차도 서버에 저장되어 있기 때문에 취약성과 위험은 존재합니다.


비밀번호 관리 솔루션


SAC의 자동로그인 기능을 사용하는 이유는 비밀번호 관리의 어려움을 극복하기 위해서 입니다. 비밀번호를 관리해주는 솔루션은 세가지 정도가 있습니다.


먼제 계정관리(Identity Management) 솔루션입니다. 전문적인 계정관리 솔루션으로서 계정의 비밀번호를 주기적으로 자동으로 변경해주는 기능을 갖고 있습니다. 다만 변경된 비밀번호는 별도로 DB 저장하지 않는 것이 원칙입니다. 그래야만 합니다. ^^


그리고 두번째는 SAC 솔루션입니다. 자동으로 계정의 비밀번호를 변경하고 비밀번호를 복호화 가능하도록 SAC 관리서버의 DB에 저장한 뒤 사용자들이 서버에 접속할 때 비밀번호를 복호화하여 자동으로 입력해 줍니다. 서버 관리자들은 비밀번호를 직접 변경하지 않아도 되고 기억하지 않아도 되기 때문에 매우 편리하겠지만 분명히 "위법"입니다.


그리고 세번째는 랜덤 비밀번호 관리 솔루션입니다. 외산으로는 TPAM 이라는 솔루션이 있고 국산으로는 최근 개발된 시큐어가드테크놀로지의 APPM 이라는 제품이 있습니다. 이 제품들은 평소에는 계정의 비밀번호를 랜덤하게 생성하여 접속을 차단하고 사용자가 특정 계정의 사용을 신청하면 랜덤하게 비밀번호를 다시 변경한 뒤 변경된 비밀번호를 신청자에게 전송하여 접속 할 수 있도록 해줍니다. 그리고 사용 신청 시간이 지나면 다시 랜덤비밀번호를 생성하여 변경하는 방식으로 운영됩니다.


하지만 두번째와 세번째 솔루션 모두 관리 솔루션 내의 DB에 복호화 가능한 형태로 비밀번호가 저장된다는 점에서 개인정보보호법의 위반 소지가 있습니다. 다만 세번째 솔루션의 경우 두번째 솔루션들 처럼 일반 사용자가 접속하지 않는 관리서버의 DB 혹은 별도의 비교적 안전한 보안USB 등에 저장한다라는 점에서 물리적인 접근통제와 SecureOS의 설치 등을 통해 보안을 강화하면 SAC 솔루션 보다는 안전할 것으로 보입니다.


일부 업체에서 패스워드를 결코 저장하지 않는다고 우기는 경우도 있는데 그것은 기술적으로 불가능합니다.


2차 인증의 필요성


비밀번호의 관리 문제로 인해 여러 비밀번호 관리 솔루션 들이 출시되었지만 비밀번호가 복호화 가능한 암호화 기법으로 DB에 저장된다는 점에서 컴플라이언스 측면의 문제가 있습니다. 단지 비밀번호 관리의 편의성만을 강조한 솔루션들이기 때문입니다.


때문에 2차 인증이 추가적으로 적용되어야 합니다. 그래서 2013년 12월 개정된 IT 금융감독 규정에 서버의 계정으로 접속 시 2차 인증 의무화가 명시되었습니다. 하지만 법의 모호함은 SAC 서버에 접속할 때 2차인증을 서버 계정의 접속 시 2차 인증으로 인정할 것인가라는 논란거리를 만들고 있습니다. 하지만 분명히 "서버 계정의 접속"에 2차 인증 적용이기 때문에 SAC에 접속할 때 2차 인증은 인정받지 못할 가능성이 높습니다.


이래 저래 기업과 공공기관의 보안 담당자들은 서버의 보안강화를 위해 솔루션을 도입할 때 고려해야 할 사항들이 참 많습니다.


신고
이 댓글을 비밀 댓글로
  1. 세번째 방식의 경우
    사전에 SSL 키를 접속하고자 하는 타켓서버에 공유를 하고 있어야 하지 않나요?
    키 방식으로 접속을 해서 비밀번호를 생성하는 형태가 될거 같은데요.
    그리고 그 비밀번호 생성 관리를
    일반 사용자들이 사용하지 않는 관리자 서버에서 한다는거 아닌가요?
  2. 덕분에 비밀번호를 관리해주는
    세가지 솔루션을 알게되었습니다.^^
    정말 보안 담당자들은 고려해야 할
    부분이 많으네요...ㅎㅎ
    좋은 시간 보내세요!

SSL v3의 POODLE 취약점에 대하여

Posted by taeho Tae-Ho
2014.10.17 13:57 정보보호

SSL Padding Oracle On Downgraded Legacy Encryption(POODLE) Vulnerability


요약


2014년 10월 14일에 블록암호화기법인 CBC(Cipher Block Chaning)모드를 사용하는 SSL version 3 프로토콜의 취약성이 발표되었다. SSL v3는 TLS 프로토콜 상에서 동작하도록 설계된 통신상의 암호화를 담당하는 프로토콜의 하나다. 이 취약성에 의해 해커는 암호화 되어 통신중인 암호문 중 일부(subset)를 평문으로 복호화할 수 있다.


상세내용


SSL v3는 IPv4와 IPv6와 같은 IP프로토콜 상에서 암호화 통신을 위해 사용되는 암호화 통신 프로토콜이다. 이 취약성은 블록암호화기법인 CBC 모드를 사용할 경우 발생하는 패딩 된 암호블록(the block cipher padding)이 MAC(메시지 인증 코드)에 의해 보호되지 않기 때문에 발생한다.


해커는 이 취약점을 갖고 있지 않은 TLS의 버전을 사용하는 클라이언트와 서버의 핸드쉐이크 과정에 끼어들어(Man in the middle attack) TLS가 지원되지 않는다는 형태의 변조된 메시지를 클라이언트에게 전송해 TLS가 아닌 SSL v3로 다운그레이드 시켜(downgrade dance attack) 통신 데이터의 일부를 해커가 해독하는데 이 취약점을 악용할 수 있다.


이 취약점과 유사한 취약점들이 이전에도 SSL v3 프로토콜의 RC4와 같은 스트림 암호에서 발견되었기 때문에 SSL v3에 대하여 더 이상 사용하지 않을 것을 이제 고려하여야 한다. 이 취약점은 프로토콜 자체의 문제이다.


SSL v3는 웹의 HTTPS를 지원하는 웹-기반 관리도구들과 SSL VPN, 보안SIP 또는 파일 전송등의 도구에서 광범위하게 사용된다.


대응

이 취약점은 SSL의 상위 버전 암호화 프로토콜인 TLS 1.0 이상의 버전을 사용해야 하며 TLS의 핸드쉐이크 과정에서 SSL v3로 다운그레이드가 되지 않도록 하는 옵션이 보안 장비나 소프트웨어(IE 및 클라이언트SW)에서 지원되어야 한다. 


신고
이 댓글을 비밀 댓글로

bash 취약점이 얼마나 위험한가?

Posted by taeho Tae-Ho
2014.10.10 16:36 정보보호

얼마 전 전 세계적으로 이슈가 된 bash 취약점에 대한 포스트를 쓴 적이 있습니다. 그런데 아무래도 이 취약점에 대한 보안 업계 사람들의 과잉 반응이 심상치 않습니다. 과연 bash 취약점의 본질을 제대로 이해하고 있는지 의구심이 들 정도입니다.


bash 취약점은 물론 심각하게 악용될 수 있습니다. 하지만 중요한 것은 원격지에서 bash 취약점을 단독으로 악용하여 서버에 접근할 수는 없다는 점입니다. 


bash는 사용자에게 명령어를 입력 받아 명령어에 해당되는 파일을 사용자 대신 프로그램이 서버의 메모리에 로드되고 실행될 수 있도록 해주는 프로그램입니다. 그리고 bash는 단독으로 서버에서 실행되어 통신을 통해 명령어를 전달 받는 통신 기능이 없습니다.


즉 bash 취약점을 이용해 원격에서 직접 아래와 같은 명령을 쉘에게 전달할 수는 없습니다. 



위의 명령을 변형하여 서버에서 해커가 원하는 명령을 실행하기 위해서는 서버에서 실행중인 서비스에 접속할 수 있어야 합니다. 그리고 그 서비스의 취약점을 찾아 bash 명령어든 아니면 배치작업 등에 의해 실행중인 bash에 접근할 수 있어야 합니다.


가장 단순한 형태로 bash 취약점을 원격에서 악용할 수 있는 가상의 시나리오를 그림으로 그려보면 다음과 같습니다.


즉 원격에서 해커가 서버의 bash취약점을 이용해 공격을 하려면 위 그림과 같이 일단 서버에 접근할 수 있는 서비스를 찾아야 합니다. 가장 찾기 쉬운 서비스가 바로 웹 서비스일 겁니다. 웹서버에서 bash를 호출하거나 실행중인 bash에 접근할 수 있는 웹서버의 취약점을 찾는다면 bash 취약점을 이용해 명령을 실행시킬 수 있습니다. 이 단계까지 갈 수 있다면 해커는 서버를 장악한 것과 다름없습니다. 웹쉘이 서버에 업로드 된 것과 같죠.


하지만 원격에서 위의 그림에 있는 web server 취약점 공격 없이 직접 bash에게 접근해 공격코드를 삽입할 수는 없습니다. 그런데도 불구하고 국내외의 많은 보안인들은 이점을 정확하게 설명하지 않은 채 마치 취약한 bash가 서버에 있으면 100% 해킹할 수 있는 것 처럼 과장하고 있습니다. 당장 취약점 방어가 가능한 IPS, F/W 등 보안 솔루션을 도입하라고 말입니다. 


보안업계가 아닌 다른 분야에서 일을 배우기 시작한 제가 볼 때는 이런 호들갑(?)은 보안 업계에만 있는 독특한 특징입니다. 대 고객 기만처럼 느껴질 때가 많습니다. 물론 취약점을 내포한 채 시스템을 운영해서는 안되겠죠. 하지만 취약점에 대한 정확한 정보 전달 없이 그저 "이 취약점은 이만큼 위험하니 이것 저것 해야 한다" 식의 엄포를 놓는 것은 썩 바람직해 보이지는 않습니다.


그리고 그런 사람들의 공통점은 서버의 운영체제와 서비스애플리케이션, 시스템소프트웨어의 상관관계에 대해 깊은 이해가 부족하다는 점입니다.


bash 취약점은 심각한 보안 취약성 임에는 분명합니다. 하지만 서두르거나 호들갑을 떨 필요는 없습니다. 정확한 취약점 식별과 취약점 분석을 통해 위협을 제거하면 됩니다. 


현재까지는 bash를 패치하는 것이 가장 확실한 방법입니다. 그래도 불안하다면 RedCastle과 같은 SecureOS를 통해 웹서버 서비스 대몬(httpd, java, htmls)이나 DB 서비스대몬 및 기타 서비스 대몬들이 bash를 읽거나 실행하지 못하도록 커널 수준에서 차단하는 것이 현재까지는 가장 확실한 보호대책입니다.


IPS, 웹방화벽 등 네트워크 기반의 보안 솔루션으로는 bash 취약점 공격을 제대로 방어할 수 없습니다.

신고
이 댓글을 비밀 댓글로
  1. 때때로 한국에서는 제품보다는 약을 파는 차력사들이 많은 느낌입니다 ^^

웹페이지 변조(파일변조)를 차단하는 근본적인 방법

Posted by taeho Tae-Ho
2014.10.10 12:23 정보보호

웹페이지의 변조는 매우 오래된 해킹 형태입니다. 그 오랜 시간 동안 매우 다양한 대책이 제시되었고 최근에는 웹페이지 소스파일의 변조를 주기적으로 탐지하는 솔루션까지 등장하였습니다. 하지만 변조를 근본적으로 차단하는 보안 솔루션이 있음에도 아직까지 많은 기업이나 기관들이 실 적용을 하지 못하고 있는 경우가 많습니다.


그 보안 솔루션은 바로 SecureOS 제품인 RedCastle입니다. (사실 다른 SecureOS 제품들도 가능하지만 그 편의성이나 안정성 그리고 정책 구현의 다양함은 RedCastle이 월등합니다. 그리고 MAC 스푸핑등에 의한 실제 파일을 변조하지 않고 네트워크 수준에서 변조하는 기법은 네트워크 보안 솔루션을 통해 방어해야 합니다.)


서버 보안 정책 수립에 대한 교육이 있어 새롭게 Solaris 11 서버를 VMWARE로 구성하고 웹쉘을 통한 소스 변조 시연과 방어를 실습하도록 구성한 김에 블로그에 그에 대한 과정을 한번 포스팅해 봅니다. 이런 저런 방안들을 고민하는 보안 담당자들이 많은데 RedCastle을 활용해 가장 근본적인 수준에서 웹 서버의 소스파일에 대한 위변조를 통제하는 방안으로 RedCastle을 검토해 보는 것도 좋을 것 같습니다.


먼저 Solaris 11 가상머신입니다. 10월초에 다운받은 따끈따끈한 버전입니다.



Solaris 11에 설치한 tomcat (version 6)과 index.jsp 소스파일입니다. index.jsp에는 Hello tomcat..!! 메시지와 제 블로그 주소만 들어 있습니다.



업로드 된 것으로 가정한 웹쉘입니다. 매우 유명한 웹쉘인데 운영체제의 명령어 실행은 물론 탐색기 형태의 디렉토리 브라우징과 파일의 다운로드/업로드 그리고 text 형태의 문서에 대한 편집까지 가능합니다. 일단 웹서버에 업로드되면 그 웹서버에게는 사망선고가 내려집니다.


웹쉘(webshell)의 위험성과 서버보안S/W(RedCastle SecurOS)를 이용한 차단 방법  보러가기



위의 화면에서 적색으로 표시된 index.jsp 파일에 대해 edit 링크를 클릭해 아래와 같이 편집 모드로 넘어갑니다.



위는 원본파일의 내용입니다. 아래와 같이 <script> 태그를 이용해 내용을 추가합니다. 이 웹서버에 접속한 사용자의 브라우저 화면에 메시지 창을 띄우는 javascript 입니다.



save 버튼을 눌러 저장한 뒤 브라우저에서 웹서버에 접속해 봅니다.



메시지 창이 뜹니다. index.jsp 파일이 변조된 것이지요. 일단 서버에 웹쉘이 업로드 되면 해커는 서버를 90% 쯩 장악한것과 같습니다. 그리고 이러한 웹서버 소스파일의 변조는 웹쉘만 가능한 것이 아닙니다. 소스자체의 취약점과 웹서버의 버그에 의한 취약점 혹은 APT 공격을 통해 서버에 침투한 경우 모두 가능합니다. 이러한 경우에 모두 대응해 웹서버의 소스파일을 보호할 수 있는 보안 솔루션은 RedCastle 밖에는 없다고 보는 것이 옳습니다.


아래와 같이 웹서버의 소스파일(객체명 : WWW_SOURCE)과 운영체제의 명령어 시스템파일(객체명 : Sun_System)에 대한 정책을 세웁니다. 



WWW_SOURCE 객체가 바로 웹서버 소스파일에 대한 보호 정책입니다. *.jsp 파일과 *.js 파일에 대해 모든사용자(Any)에게 r (읽기)만 허용하는 정책입니다. 소스의 수정에 대한 정책은 이 정책을 수정하여 수정권한을 따로 부여하여야 합니다. 컨설턴트들과 협의하여 수정권한을 부여하는 정책수립 과정이 필요하죠.


위의 정책이 적용되면 아래와 같이 동일한 방법으로 소스파일의 변조를 시도하면 에러가 발생하면서 차단이 됩니다.



당연히 상세한 위반로그가 남게 됩니다. 위의 에러 페이지에서는 Permission Denied가 발생하게 되는데 해커는 왜 permission Denied가 발생하는지 알 수 없습니다. RedCastle의 감사로그를 봐야만 tomcat이 실행중인 java 대몬이 index.jsp 파일에 대해 수정을 시도해 차단된다는 것을 알 수 있습니다.

물론 root 권한으로 로그인하여 vi 편집기를 통해 index.jsp 를 수정하는 것도 차단됩니다. 웹 취약성 뿐만 아니라 서버에 관리자 권한으로 침투한 해커의 소스 변조 시도도 완벽하게 차단하고 실시간으로 알림을 받을 수 있습니다.


이러한 웹 소스변조 차단을 구현하기 위한 RedCastle을 이용한 보안 정책 수립 과정은 RedCastle Advanced Course 과정의 교육을 받으면 실습해 볼 수 있습니다.


네트워크 수준의 서버 해킹차단을 위한 공격패턴 위주의 방어기법과는 차원이 다른 수준의 안전함을 느낄 수 있을 겁니다.

신고
이 댓글을 비밀 댓글로